Hi Jun, A couple of points below.
On Sat, Apr 9, 2016 at 12:19 AM, Jun Rao <j...@confluent.io> wrote: > 5. Your main request is how can a client know that the broker is now > supporting new SASL mechanisms. One way to support that is to adjust KIP-43 > slightly. We can model the SaslMechanismRequest as a regular request (with > standard request header) and add that to our protocol definition. Version 0 > The current compatibility story for older clients in KIP-43 is that we send the mechanism first as that can be distinguished from the bytes sent by the GSSAPI in 0.9.0.0. If we use the standard request header for SaslMechanismRequest (which I agree would be a nice thing to do) then we would be sending the api key (INT16) first. > of this request indicates that it supports GSSAPI and SASL Plain. If we > support any additional mechanism in the future, we will bump up the version > of SaslMechanismRequest. We also add in the protocol documentation that the > SASL authentication protocol is SaslMechanismRequest followed by token > exchange from SASL library. If we pick the current proposal in KIP-35, when > the client issues ApiRequest, we will return the supported versions > for SaslMechanismRequest as well. Does this work for you? > Currently, authentication would have to succeed before any application layer request can be sent. To make sure I understand correctly, are you suggesting that we would change it so that an ApiVersionRequest would be possible before authentication happens (so that the client would then know the supported versions of SaslMechanismRequest)? Thanks, Ismael
