Hi Nelson, Thank you for writing up the KIP! My apologies for the delay in response :(
Questions: 1. Is the long-term plan to keep the configuration default set to “false"? I understand the short-term benefits, but in general, configuration defaults should prefer compliance with standards (e.g. RFCs). 2. Can we change “sasl.oauthbearer.header.urlencode.enable” to be a little shorter? Maybe “sasl.oauthbearer.header.urlencode” or even “sasl.oauthbearer.urlencode”? I’m looking at the configuration names that I introduced in KIP-768 with a bit of cringe at their length :) This is a total nit, so I won’t make a stink about it if everyone else is cool with it :) Thanks, Kirk > On Mar 13, 2024, at 5:31 AM, Nelson B. <bachmanity...@gmail.com> wrote: > > Hi all, > > I just wanted to bump up this thread. > > The KIP introduces a really small change and PR is already ready and only > waiting for this KIP to get approved to be merged. > > Thanks, > > On Wed, Mar 6, 2024 at 12:26 PM Nelson B. <bachmanity...@gmail.com> wrote: > >> Hi all, >> >> I would like to start a discussion on KIP-1025, which would optionally >> URL-encode clientID and clientSecret in the authorization header >> >> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1025%3A+Optionally+URL-encode+clientID+and+clientSecret+in+authorization+header >> >> Best, >> Nelson B. >>
