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
