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
>
