Rajini, the KIP wiki is a bit unclear on the protocol changes. Could you document the proposed Kafka protocol requests&responses in the standard format (as on "A guide to the Kafka protocol"). This information should also be added to that page when the KIP is accepted. I think it would also be good to clarify what SASL handshake means, if that is the Kafka-leved SASL mechanism handshake or the opaque SASL data handshake performed by the SASL libraries.
Thanks, Magnus 2016-04-19 17:20 GMT-07:00 Jun Rao <j...@confluent.io>: > Just to close the loop on this. Discussed with Magnus offline on how KIP-43 > and KIP-35 can play together. We agreed upon the following proposal. > > On a SASL port, > > client sends: > > ApiVersionRequest (optional), SaslHandshakeRequest, SASL tokens (size > delimited as being done now), regular api requests > > client receives: > > ApiVersionResponse (optional), SaslHandshakeResponse, SASL tokens (size > delimited as being done now), regular api responses > > The format of SaslHandshakeRequest is what's currently described in > KIP-43. There > will be some minor tweaks on ApiVersionResponse, which Magnus will follow > up in the KIP-35 thread itself. > > Thanks, > > Jun > > > On Wed, Apr 13, 2016 at 5:59 AM, Rajini Sivaram < > rajinisiva...@googlemail.com> wrote: > > > I have updated the PR (https://github.com/apache/kafka/pull/812) and > > KIP-43 > > to use standard Kafka format for the new request/response added by > KIP-43. > > I haven't changed the overall structure of the Java code. Feedback is > > appreciated. > > > > Thanks, > > > > Rajini > > > > On Tue, Apr 12, 2016 at 3:52 PM, Ismael Juma <ism...@juma.me.uk> wrote: > > > > > Hi Jun, > > > > > > Comments inline. > > > > > > On Mon, Apr 11, 2016 at 1:57 AM, Jun Rao <j...@confluent.io> wrote: > > > > > > > Yes, that should be fine right? Since the new api key will start with > > a 0 > > > > byte, it actually guarantees that it's different from 0x60 (1st byte > in > > > the > > > > old protocol) even if we change the request version id in the future. > > > > > > > > > Yes, this is true. Also, the GSS API library will throw an exception if > > the > > > first byte is not 0x60 (for the case where newer clients connect to > older > > > brokers): > > > > > > > > > > > > https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/sun/security/jgss/GSSHeader.java#L97 > > > > > > > > > And the DEFECTIVE_TOKEN status code is specified in both RFC 2743[1] > and > > > RFC 5653[2]. Section 3.1 of RFC 2743 specifies that the token tag > > consists > > > of the following elements, in order: > > > > > > 1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that > > > -- constructed form, definite length encoding follows. > > > > > > 2. Token length octets ... > > > > > > > > > Ismael > > > > > > [1] Generic Security Service Application Program Interface Version 2, > > > Update 1: https://tools.ietf.org/html/rfc2743 > > > [2] Generic Security Service API Version 2: Java Bindings Update: > > > https://tools.ietf.org/html/rfc5653 > > > > > > Ismael > > > > > > > > > > > -- > > Regards, > > > > Rajini > > >
