I was thinking about this a little more and would like to summarize the current state:
hive-site.xml -> transport -> JDBC connection string
1. hive.server2.authentication=NOSASL -> raw transport -> jdbc:hive2://host:port/dbname;auth=noSasl
2. hive.server2.authentication=NONE -> plain SASL transport -> jdbc:hive2://host:port/dbname (DEFAULT)
3. hive.server2.authentication=KERBEROS -> Kerberos SASL transport -> jdbc:hive2://host:port/dbname;principal=<principal>
So we need to set auth=noSasl to disable SASL instead of auth=plainsasl|kerberos to enable SASL.
Now if the server is set to Kerberos, then the client still has to know this because it if they exclude the principal parameter it will happily initialize a plain SASL transport because the code infers SASL/Kerberos based on the existence of that value. Granted, in this case the connection throws an exception.
If it was a requirement to include say auth=plainsasl|kerberos in the connection string, then the code wouldn't have to guess what the intent was and could communicate an error if auth=kerberos and principal is not present.
Furthermore, from what I can see, the plain SASL is really just a no-op as it is not doing anything when authentication=NONE.
In the end, it comes down to the fact that the client still needs to know the authentication method of the server.
That is why I asked whether we had data about the average use case. Do we know how often people are using raw vs plain vs kerberos?
It seems that the real issue is that a SASL transport doesn't play nicely with a raw transport. If it would be possible to remove the need to support the raw transport, that would resolve this discussion. Even the raw transport much speak thrift, so that isn't an issue. Rather it is a question of whether client should be forced to implement a SASL transport.