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
