Yeah. This gets us close to Ewen's feature-version suggestion, since we need to version things that are not tied to specific Requests.
Gwen On Mon, Apr 4, 2016 at 12:20 PM, Ismael Juma <ism...@juma.me.uk> wrote: > An option would be to add a version for the handshake in the KIP-35 > response. > > Ismael > On 4 Apr 2016 20:09, "Gwen Shapira" <g...@confluent.io> wrote: > > > I think the challenge here is that even after KIP-35 clients will not > know > > whether the server supports new sasl mechanisms or not, so non-Java > clients > > will have to assume it is not supported (and will therefore lag behind on > > features). > > > > I think this highlights a short-coming of KIP-35, and I'm wondering if > > there are good ways to address this. > > > > Gwen > > > > > > On Mon, Apr 4, 2016 at 12:05 PM, Jun Rao <j...@confluent.io> wrote: > > > > > I think with KIP-43, the existing way of sasl handshake during > connection > > > still works. It's just that if you want to support non-GSSAPI, you will > > > need a new sasl handshake implementation in the client. It's > unfortunate > > > that Protocol currently only covers the communication after the > > connection > > > is ready to use, but not during handshake. For now, we can probably > just > > > document this change during handshake since changing the implementation > > is > > > optional. > > > > > > Thanks, > > > > > > Jun > > > > > > On Mon, Apr 4, 2016 at 11:28 AM, Gwen Shapira <g...@confluent.io> > wrote: > > > > > > > Hi Kafka Team, > > > > > > > > As a practical test-case of KIP-35, I'd like to turn your attention > to > > > > KIP-43: > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-43 > > > > > > > > KIP-43 makes an interesting modification to the protocol, but only > > under > > > > specific conditions: > > > > > > > > "*Client flow:* > > > > > > > > 1. If sasl.mechanism is not GSSAPI, send a packet with the > mechanism > > > > name to the server. Otherwise go to Step 3. > > > > - Packet Format: | Version (Int16) | Mechanism (String) | > > > > 2. Wait for response from the server. If the error code in the > > > response > > > > is non-zero, indicating failure, report the error and fail > > > > authentication. > > > > 3. Perform SASL authentication with the configured client > mechanism > > > > > > > > *Server flow:* > > > > > > > > 1. Wait for first authentication packet from client > > > > 2. If this packet is a not valid mechanism request, go to Step 4 > and > > > > process this packet as the first GSSAPI client token > > > > 3. If the client mechanism received in Step 2 is enabled in the > > > broker, > > > > send a response with error code zero and start authentication > using > > > the > > > > specified mechanism. Otherwise, send an error response including > the > > > > list > > > > of enabled mechanisms and fail authentication. > > > > - Packet Format: | ErrorCode (Int16) | EnabledMechanisms > > > > (ArrayOf(String)) > > > > | > > > > 4. Perform SASL authentication with the selected mechanism. If > > > mechanism > > > > exchange was skipped, process the initial packet that was received > > > from > > > > the > > > > client first." > > > > > > > > > > > > I'd love to know how this will be communicated to clients via > > > > VersionRequest proposed in KIP-35 (mostly because Jun and I need to > > > review > > > > KIP-43 and we want to be sure we are not breaking the new protocol at > > the > > > > same time we introduce it) > > > > > > > > Do we: > > > > 1. Bump protocol version of every single Request? Even though unless > > you > > > > are using a new sasl mechanism nothing changes? > > > > 2. Ignore and not bump protocol? If so, how will clients know that > new > > > > sasl.mechanisms are supported? > > > > 3. Something else? > > > > > > > > Gwen > > > > > > > > > >
