Hi Alieh, Thanks for the review. AS01: The KIP doesn't specify what the broker does with this information. I envisage that the broker adds it to the request context for the client. The motivation is primarily easier problem determination through awareness of whether a client is being used via a framework which might have its own special behaviour in areas such as retries.
AS02: I chose tagged fields because they will only be populated for client connections from frameworks. It is a debatable point and I'd like to see what some other reviewers say. I'm open to following a consensus here. AS03: Nice catch. Copy-paste error fixed. Thanks, Andrew On 2026/07/20 13:03:39 Alieh Saeedi via dev wrote: > Thanks Andrew for the KIP. Nice to solve a long standing gap. > > I had a couple of questions/concerns: > > AS01: What does the broker do with the info it receives? Are they > represented as JMX metrics, or do they appear in the logs somewhere? > AS02: I don't understand why we moved to v6 while the new configs are added > by tag? Should not we either bump to a new version or add a field by tag? > It seems you have done both in this KIP. Also if we have 0-6 in the > request, should it be mirrored in the response as well (based on > convention)? > AS03: The regex may need a leading `[`?! > > - Alieh > > On Fri, Jul 17, 2026 at 8:53 PM Andrew Schofield < > [email protected]> wrote: > > > Hi, > > I'd like to open discussion on KIP-1368: Client framework name and version. > > > > Applications often use application frameworks such as Spring to connect to > > Kafka. To assist with problem diagnosis, this KIP introduces a way to > > provide the framework name and version as part of the metadata the client > > sends to the broker when it connects. > > > > Here's the KIP: > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/x/J4Q_Gg__;!!Ayb5sqE7!tBX_Vot3WfLZ7u5F51LRStX0Y45p1mCaq0kxvQxJTroDf1BCLxrxvauCOcoRxTcRXrIVR2kqHzQOa6HBwXd9YblARWoF6w$ > > > > Thanks, > > Andrew >
