Hi Jun, JR7: Done.
Thanks, Andrew On 2026/09/24 16:20:08 Jun Rao via dev wrote: > Hi, Andrew, > > Thanks for the updated KIP. > > JR7. Piggybacking on the version bump in 4.5 sounds good to me. Could we > document the version bump in the KIP? > > Jun > > On Thu, Sep 24, 2026 at 7:32 AM Andrew Schofield <[email protected]> > wrote: > > > Hi Jun, > > Thanks for your reply. > > > > JR7: There is a tension here between bumping the version when adding these > > tagged fields because it is a new feature and not doing so because of the > > negotiation aspects of this. I believe that AK 4.5 will introduce a new > > version of ApiVersions anyway because of KIP-1313, so the best path is > > probably to piggyback the tagged field addition onto that new version. > > > > JR8.1: I've added this constraint in AK 5.0 since we need a major version > > to enforce this. In practice, nobody will be hit by this limit. > > JR8.2: Yes, constraint added to the configs too. > > > > Thanks, > > Andrew > > > > On 2026/09/24 00:08:16 Jun Rao via dev wrote: > > > Hi, Andrew, > > > > > > Thanks for the updated KIP. > > > > > > JR7. Currently, we always bump the version when adding a tagged field. > > The > > > intention of this KIP is to add the two tagged fields without a version > > > bump. This choice seems reasonable since it avoids an extra round of > > > ApiVersionRequest version negotiation when 4.5 clients talk to 4.4 > > servers. It > > > would be useful to be explicit document there is not version bump for > > > ApiVersionRequest. > > > > > > JR8. "The maximum length of the fields is 249 characters" > > > JR8.1 Should the length constraint also apply to the existing fields > > > ClientSoftwareName and ClientSoftwareVersion? > > > JR8.2 Should we add a length constraint for the two new client > > > configurations? > > > > > > Jun > > > > > > On Wed, Sep 23, 2026 at 6:42 AM Andrew Schofield <[email protected]> > > > wrote: > > > > > > > Hi Jun, > > > > Thanks for the reply. > > > > > > > > JR6: Yes, that works. I've added the methods to ClientTelemetryContext. > > > > Let me know what you think. > > > > > > > > Thanks, > > > > Andrew > > > > > > > > On 2026/09/21 17:54:38 Jun Rao via dev wrote: > > > > > Hi, Andrew, > > > > > > > > > > Thanks for the reply. > > > > > > > > > > JR6. It seems weird that the implementation of a KIP-714 plugin > > requires > > > > > casting an authorizableRequestContext to an internal class > > > > RequestContext. > > > > > Would it be better to expose all client related resource labels > > through a > > > > > public API in ClientTelemetryContext? > > > > > > > > > > Jun > > > > > > > > > > On Mon, Sep 21, 2026 at 6:43 AM Andrew Schofield < > > [email protected]> > > > > > wrote: > > > > > > > > > > > Hi Jun, > > > > > > Thanks for the reply. > > > > > > > > > > > > JR4: Done. Producer, consumer and admin. > > > > > > > > > > > > JR5: Yes. I've reworded slightly. > > > > > > > > > > > > JR6: I think the plugin implementation already needs to do > > something > > > > > > similar to get to software name/version. > > > > > > ClientTelemetryContext.authorizableRequestContext() returns an > > > > instance of > > > > > > AuthorizableRequestContext. The > > o.a.k.common.requests.RequestContext > > > > class > > > > > > implements that interface, and it also lets you get to > > > > ClientInformation > > > > > > and that's where you can find the software name/version and > > framework > > > > > > name/version. You can see this in > > > > > > o.a.k.server.metrics.ClientMetricsInstanceMetadata. I would > > describe > > > > this > > > > > > as grubby :) > > > > > > > > > > > > One way forward here would be to remove the broker-added resource > > > > labels > > > > > > from KIP-1368, but leave the additions to the match criteria. Then > > it > > > > would > > > > > > still be possible to specify, for example, that particular metrics > > > > should > > > > > > be captured for Kafka Streams clients only, without adding to the > > > > > > grubbiness. > > > > > > > > > > > > Thanks, > > > > > > Andrew > > > > > > > > > > > > On 2026/09/15 20:44:06 Jun Rao via dev wrote: > > > > > > > Hi, Andrew, > > > > > > > > > > > > > > Thanks for the reply. A few more comments. > > > > > > > > > > > > > > JR4. "The configuration keys are defined in > > > > > > > org.apache.kafka.clients.CommonClientConfigs" > > > > > > > Could you explicitly list the clients (producer, consumer, > > > > AdminClient, > > > > > > > etc.) that define the two new configs? > > > > > > > > > > > > > > JR5. Should AK frameworks such as kstream and connect set > > > > > > > client.framework.name and client.framework.version in their > > clients > > > > > > > automatically? > > > > > > > > > > > > > > JR6. "Broker-added resources labels for client metrics" > > > > > > > Are the new labels added in > > > > DefaultClientTelemetryContext.RequestContext? > > > > > > > Since ClientTelemetryExporter.exportMetrics() only takes > > > > > > > ClientTelemetryContext, does the implementor need to cast it > > > > > > > to DefaultClientTelemetryContext to retrieve the new labels? > > > > > > > > > > > > > > Jun > > > > > > > > > > > > > > On Fri, Sep 11, 2026 at 12:48 PM Andrew Schofield < > > > > [email protected] > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hi Jun, > > > > > > > > JR1: I dug into the KIP-714 client metrics stuff a bit more > > and I > > > > have > > > > > > > > revised the KIP. I have added client-framework-name and > > > > > > > > client-framework-version to the set of keys in the matching for > > > > client > > > > > > > > metrics, and also added these broker-added metrics tags. This > > is > > > > how > > > > > > these > > > > > > > > pieces of information would have been incorporated into > > KIP_714 had > > > > > > they > > > > > > > > been part of Kafka at that point. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Andrew > > > > > > > > > > > > > > > > On 2026/08/04 20:29:19 Andrew Schofield wrote: > > > > > > > > > Hi Jun, > > > > > > > > > Thanks for the response. > > > > > > > > > > > > > > > > > > JR1: My intent here is only request logging. It would be > > > > possible to > > > > > > add > > > > > > > > client-framework-name and client-framework-version to the match > > > > > > criteria > > > > > > > > for client metrics, which could conceivably permit scenarios > > such > > > > as > > > > > > > > capturing metrics from specific versions of the Spring > > framework. > > > > This > > > > > > is > > > > > > > > beyond the scope I have in mind. > > > > > > > > > > > > > > > > > > JR3: Thanks for clarifying the tagged field conventions. > > Version > > > > bump > > > > > > > > reverted. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > On 2026/08/04 18:38:40 Jun Rao via dev wrote: > > > > > > > > > > Hi, Andrew, > > > > > > > > > > > > > > > > > > > > Thanks for the reply. > > > > > > > > > > > > > > > > > > > > JR1. ClientSoftwareName and ClientSoftwareVersion are used > > in > > > > > > metric > > > > > > > > names > > > > > > > > > > and match predicates for configuring client metrics. Are > > > > > > > > ClientFrameworkName > > > > > > > > > > and ClientFrameworkVersion used in those places too or are > > they > > > > > > only > > > > > > > > used > > > > > > > > > > in request logging? > > > > > > > > > > > > > > > > > > > > JR3. The general rule for adding a new field in RPC is that > > > > (1) if > > > > > > it's > > > > > > > > > > truly optional, we add it as a tagged field with no version > > > > bump; > > > > > > (2) > > > > > > > > > > otherwise, we add it as a non-tagged field with a version > > > > bump. One > > > > > > > > > > exception is when adding a non-optional field in the > > request > > > > > > header. > > > > > > > > > > Because of the limitation in existing implementation, we > > need > > > > to > > > > > > add > > > > > > > > it as > > > > > > > > > > a tagged field with a version bump. > > > > > > > > > > > > > > > > > > > > Jun > > > > > > > > > > > > > > > > > > > > On Tue, Aug 4, 2026 at 6:04 AM Andrew Schofield < > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi Jun, > > > > > > > > > > > Thanks for your response. > > > > > > > > > > > > > > > > > > > > > > JR1: I've expanded the motivation section in the KIP. > > They > > > > are > > > > > > truly > > > > > > > > > > > optional, I feel. When diagnosing an issue using the > > client > > > > logs, > > > > > > > > having > > > > > > > > > > > this information can illuminate why the application is > > > > behaving > > > > > > in a > > > > > > > > > > > particular way. If the application is using a framework, > > > > > > behaviours > > > > > > > > such as > > > > > > > > > > > retries will typically not be in the application code > > itself > > > > > > because > > > > > > > > > > > they're implemented in the framework. There's a > > difference > > > > > > between > > > > > > > > what the > > > > > > > > > > > application developer thinks their code does and what we > > see > > > > in > > > > > > the > > > > > > > > logs. > > > > > > > > > > > That's the point. > > > > > > > > > > > > > > > > > > > > > > JR2: Done. They're Type.STRING, default null. I think > > they > > > > > > should be > > > > > > > > > > > importance LOW because that affects the prominence of the > > > > > > configs in > > > > > > > > the > > > > > > > > > > > documentation, but I wonder whether you agree. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > On 2026/08/03 21:39:06 Jun Rao via dev wrote: > > > > > > > > > > > > Hi, Andrew, > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the KIP. > > > > > > > > > > > > > > > > > > > > > > > > JR1. Could you describe the use cases of the two new > > > > configs > > > > > > and > > > > > > > > are they > > > > > > > > > > > > truly optional? > > > > > > > > > > > > > > > > > > > > > > > > JR2. Could you add the type and the default value for > > the > > > > new > > > > > > > > configs? > > > > > > > > > > > > > > > > > > > > > > > > Jun > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 31, 2026 at 10:23 AM Matthias J. Sax < > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the KIP Andrew. I think it will be very > > > > useful if > > > > > > we > > > > > > > > can > > > > > > > > > > > > > identify frameworks, especially our own ones > > (Connect and > > > > > > > > Streams). > > > > > > > > > > > > > > > > > > > > > > > > > > About Aditya's point: I am wondering where to draw > > the > > > > line. > > > > > > Many > > > > > > > > > > > > > examples seems to be metadata that belongs into he > > Kafka > > > > > > record > > > > > > > > > > > > > `Headers` at the application level, rather than the > > lower > > > > > > level > > > > > > > > request > > > > > > > > > > > > > headers? > > > > > > > > > > > > > > > > > > > > > > > > > > There if of course no strict logical dividing line > > > > between > > > > > > both. > > > > > > > > And > > > > > > > > > > > > > yes, the broker does not access application level > > Kafka > > > > > > record > > > > > > > > > > > > > `Headers`. But if it would be useful to let the > > broker > > > > tap > > > > > > into > > > > > > > > > > > > > application level record `Headers` we should tackle > > it > > > > > > > > independently? > > > > > > > > > > > > > > > > > > > > > > > > > > Personally, I don't think it would be the right > > design to > > > > > > push > > > > > > > > too many > > > > > > > > > > > > > thing into the lower level request headers. So I am > > in > > > > favor > > > > > > of > > > > > > > > only > > > > > > > > > > > > > added the two new propose `ClientFrameworkName` and > > > > > > > > > > > > > `ClientFrameworkVersion` fields. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Matthias > > > > > > > > > > > > > > > > > > > > > > > > > > On 7/31/26 7:56 AM, Federico Valeri wrote: > > > > > > > > > > > > > > Changes look good. Thanks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 31, 2026 at 11:17 AM Andrew Schofield < > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> Hi Fede, > > > > > > > > > > > > > >> Thanks for your response. > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> FV1: They are set using the regular config > > properties. > > > > > > Yes, > > > > > > > > it is > > > > > > > > > > > > > possible for an end user to set arbitrary values, but > > > > then > > > > > > that > > > > > > > > would > > > > > > > > > > > also > > > > > > > > > > > > > be true of a builder or internal constructor. I've > > added > > > > a > > > > > > bit > > > > > > > > more > > > > > > > > > > > > > information in the KIP and beefed up the config > > > > descriptions > > > > > > to > > > > > > > > > > > discourage > > > > > > > > > > > > > application use. > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> FV2: I've never encountered such nightmares > > myself. > > > > The > > > > > > > > framework > > > > > > > > > > > which > > > > > > > > > > > > > sets the config last would win. Maybe this is a > > > > motivation > > > > > > for > > > > > > > > having a > > > > > > > > > > > > > programmatic way of setting the information. We could > > > > support > > > > > > > > > > > concatenation > > > > > > > > > > > > > of framework information, but that's just pandering > > to > > > > these > > > > > > > > people. > > > > > > > > > > > Let me > > > > > > > > > > > > > know what you think. > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> I've also updated the KIP with a maximum length > > for > > > > these > > > > > > > > pieces of > > > > > > > > > > > > > information since all identifiers should have defined > > > > bounds. > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> Thanks, > > > > > > > > > > > > > >> Andrew > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> On 2026/07/31 08:50:11 Federico Valeri wrote: > > > > > > > > > > > > > >>> Hi Andrew, the motivation looks good. A couple of > > > > > > questions: > > > > > > > > > > > > > >>> > > > > > > > > > > > > > >>> FV1: The KIP says frameworks should set them, > > but it > > > > > > does not > > > > > > > > > > > specify > > > > > > > > > > > > > >>> the mechanism. If these are ordinary user-facing > > > > configs, > > > > > > > > nothing > > > > > > > > > > > > > >>> prevents an end user from setting arbitrary > > values, > > > > which > > > > > > > > defeats > > > > > > > > > > > the > > > > > > > > > > > > > >>> purpose. Should the framework set them > > > > programmatically > > > > > > > > (builder or > > > > > > > > > > > > > >>> internal constructor) or is user override > > > > intentional? > > > > > > > > > > > > > >>> > > > > > > > > > > > > > >>> FV2: What if we have multiple layers of > > frameworks? > > > > Let's > > > > > > > > say a > > > > > > > > > > > custom > > > > > > > > > > > > > >>> framework on top of SpringBoot. I've seen similar > > > > > > nightmares > > > > > > > > in the > > > > > > > > > > > > > >>> past. > > > > > > > > > > > > > >>> > > > > > > > > > > > > > >>> Thanks > > > > > > > > > > > > > >>> Fede > > > > > > > > > > > > > >>> > > > > > > > > > > > > > >>> On Tue, Jul 28, 2026 at 8:27 AM Aditya Kousik < > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> Hi Andrew, > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> We’re definitely agreed on the increased use of > > > > > > frameworks > > > > > > > > over > > > > > > > > > > > than > > > > > > > > > > > > > the client directly. I’ve cited the different > > patterns > > > > > > Spring, > > > > > > > > > > > Micronaut, > > > > > > > > > > > > > smallrye and company-internal frameworks have APIs > > built > > > > on > > > > > > top > > > > > > > > of the > > > > > > > > > > > > > Kafka client, in a couple of KIPs already. > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> The project has enough traction that I think of > > it > > > > as > > > > > > its > > > > > > > > own > > > > > > > > > > > network > > > > > > > > > > > > > client with distributed log semantics for which > > > > frameworks > > > > > > are > > > > > > > > written, > > > > > > > > > > > > > much like gRPC over netty. People want to just write > > the > > > > > > business > > > > > > > > > > > logic and > > > > > > > > > > > > > leave the plumbing and threading to the frameworks. > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> All of this to say, I’m fine to ship the client > > > > > > framework > > > > > > > > as the > > > > > > > > > > > new > > > > > > > > > > > > > identifying parameter for frameworks to set. It will > > be > > > > > > mighty > > > > > > > > useful. > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> My addendum, rather than a pushback is that: > > guilty > > > > as > > > > > > > > charged, > > > > > > > > > > > I’m > > > > > > > > > > > > > driven by the otel/DD telemetry/observability of > > using > > > > Apache > > > > > > > > Kafka in > > > > > > > > > > > > > applications. The client.framework.version config for > > > > > > instance > > > > > > > > can be > > > > > > > > > > > used > > > > > > > > > > > > > to detect regressions and isolate root causes. But I > > > > feel it > > > > > > is > > > > > > > > only > > > > > > > > > > > one of > > > > > > > > > > > > > many such facets. You mentioned that you would use > > > > client.id > > > > > > and > > > > > > > > > > > > > clientInstanceId to identify a client but that these > > do > > > > not > > > > > > help > > > > > > > > with > > > > > > > > > > > > > aggregate/fleet-wide issues. As an example, if I tag > > an > > > > > > app’s AZ > > > > > > > > it can > > > > > > > > > > > > > help me write alerts on spike in latency in > > us-west-2. > > > > Or, > > > > > > > > detect stuck > > > > > > > > > > > > > partitions across multiple > > client.id/application.names > > > > none > > > > > > of > > > > > > > > whom > > > > > > > > > > > share > > > > > > > > > > > > > the same client.framework.name. > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> Other tags that come to mind: application.name, > > az, > > > > > > team, > > > > > > > > env, > > > > > > > > > > > rack. > > > > > > > > > > > > > All fields users usually hijack client.id for. > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> An otel JavaAgent can capture the client > > metadata > > > > > > > > registered and > > > > > > > > > > > > > attach it as tags with each resource span. Users who > > use > > > > > > > > frameworks but > > > > > > > > > > > > > rely on datadog/otel will get visibility into the > > client > > > > > > > > metadata for > > > > > > > > > > > free. > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> The KIP as I read it, serves as a foundation for > > > > future > > > > > > > > use. So I > > > > > > > > > > > > > don’t want to shoehorn a new behaviour if it > > explodes the > > > > > > scope > > > > > > > > too > > > > > > > > > > > much. > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> Best regards, > > > > > > > > > > > > > >>>> Aditya > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>>> On Jul 27, 2026, at 13:52, Andrew Schofield < > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > >>>>> Hi Aditya, > > > > > > > > > > > > > >>>>> Thanks for your response. > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > >>>>> AK1: I chose framework as the blessed > > abstraction > > > > > > because > > > > > > > > my > > > > > > > > > > > focus > > > > > > > > > > > > > was problem determination for client applications. We > > > > often > > > > > > find > > > > > > > > that > > > > > > > > > > > users > > > > > > > > > > > > > with client problems have not coded directly to the > > Kafka > > > > > > client > > > > > > > > > > > interface > > > > > > > > > > > > > because they are using a framework. As a result, > > their > > > > > > knowledge > > > > > > > > of the > > > > > > > > > > > > > application code is one level removed from the Kafka > > > > client. > > > > > > > > > > > Frameworks can > > > > > > > > > > > > > override configuration defaults, introduce different > > > > retry > > > > > > > > behaviour > > > > > > > > > > > and so > > > > > > > > > > > > > on. Lots of companies have their own internal > > > > frameworks, so > > > > > > > > this KIP > > > > > > > > > > > can > > > > > > > > > > > > > be used by them too. I'm trying to make it easier to > > > > work out > > > > > > > > when a > > > > > > > > > > > user > > > > > > > > > > > > > is making use of a framework and knowing what it is. > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > >>>>> Sometimes, particularly for non-Java clients, > > > > people > > > > > > have > > > > > > > > > > > overridden > > > > > > > > > > > > > the ClientSoftwareName/Version themselves, which > > makes > > > > those > > > > > > > > concepts > > > > > > > > > > > much > > > > > > > > > > > > > less useful than they should be. By providing > > > > > > > > > > > ClientFrameworkName/Version, > > > > > > > > > > > > > there is no longer any need to do so. That's another > > > > > > motivation > > > > > > > > here, > > > > > > > > > > > even > > > > > > > > > > > > > though KIPs don't concern themselves with non-Java > > > > clients as > > > > > > > > such. > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > >>>>> We could go for a more flexible key-value > > approach, > > > > > > but a > > > > > > > > simple > > > > > > > > > > > > > name and version is sufficient for what I had in > > mind. > > > > Feel > > > > > > free > > > > > > > > to > > > > > > > > > > > push > > > > > > > > > > > > > back with additional justification and examples. > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > >>>>> AK2: Done. o.a.k.clients.CommonClientConfigs. > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > >>>>> AK3: To identify a particular client, I would > > use > > > > > > client > > > > > > > > ID and > > > > > > > > > > > > > client-instance ID. I think these are generally more > > > > useful > > > > > > > > concepts > > > > > > > > > > > than > > > > > > > > > > > > > the framework name and version which are extra > > > > information > > > > > > for > > > > > > > > the > > > > > > > > > > > person > > > > > > > > > > > > > trying to figure out why a client is not behaving as > > > > > > expected. > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > >>>>> AK4: I'm sure you have more experience of > > > > OTel/DataDog > > > > > > > > > > > collectors. > > > > > > > > > > > > > You may well be correct that they would be helpful > > for > > > > the > > > > > > > > collectors. > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > >>>>> Thanks, > > > > > > > > > > > > > >>>>> Andrew > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > >>>>>> On 2026/07/26 07:48:20 Aditya Kousik wrote: > > > > > > > > > > > > > >>>>>> Hello Andrew, > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > >>>>>> I’m reminded of the client.id discussion we > > had > > > > back > > > > > > in > > > > > > > > > > > KIP-1313 > > > > > > > > > > > > > re: client instance id. After that discussion, I > > have a > > > > WIP > > > > > > KIP > > > > > > > > that > > > > > > > > > > > sets a > > > > > > > > > > > > > foundation for shipping client metadata tags to be > > sent > > > > for > > > > > > > > telemetry. > > > > > > > > > > > I > > > > > > > > > > > > > was hoping we could discuss if part of that approach > > > > could > > > > > > fit > > > > > > > > this > > > > > > > > > > > KIP. > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > >>>>>> AK1. I had a note on the motivation of > > selecting a > > > > > > > > “framework” > > > > > > > > > > > as a > > > > > > > > > > > > > blessed abstraction. The KIP mentions it’s for the > > client > > > > > > > > metadata and > > > > > > > > > > > > > easier problem diagnosis. This is akin to an > > > > “application id” > > > > > > > > that > > > > > > > > > > > > > non-framework clients usually tag with. > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > >>>>>> KIP-606 took an approach like > > > > > > > > metrics.context.<key>=<val>. If we > > > > > > > > > > > > > allow client.metadata.<key>=<val>, then a > > > > > > framework/application > > > > > > > > name > > > > > > > > > > > and > > > > > > > > > > > > > version can sit in such a metadata context and be > > sent > > > > with > > > > > > > > ApiVersion > > > > > > > > > > > RPC. > > > > > > > > > > > > > Of course, this is an open box approach rather than > > just > > > > the > > > > > > > > framework > > > > > > > > > > > > > name/version (just two fields) we’re adding to the > > > > protocol. > > > > > > But > > > > > > > > I’m > > > > > > > > > > > > > curious about the tier of importance of framework > > alone. > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > >>>>>> AK2. Can you clarify if this config goes into > > > > > > > > > > > > > CommonClientConfigs.java, referenced across > > > > > > > > producer/consumer/share > > > > > > > > > > > etc? I > > > > > > > > > > > > > know some share props have the “share.” prefix going. > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > >>>>>> AK3. In another thread you mentioned that the > > > > broker > > > > > > may > > > > > > > > add it > > > > > > > > > > > to > > > > > > > > > > > > > the request context. In client logs, clientId is a > > very > > > > > > useful > > > > > > > > string > > > > > > > > > > > to > > > > > > > > > > > > > identify WARN logs when things go sideways like > > broker > > > > > > > > disconnected, > > > > > > > > > > > > > rebalance in progress etc. Can you cherry pick and > > > > highlight > > > > > > some > > > > > > > > > > > useful > > > > > > > > > > > > > log places that these strings can go? I suppose > > adding > > > > > > > > > > > clientId/framework > > > > > > > > > > > > > to the MDC context might be too voluminous. > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > >>>>>> AK4. I foresee collectors like Datadog/OTel > > might > > > > find > > > > > > > > these > > > > > > > > > > > tags > > > > > > > > > > > > > useful in each span exported. > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > >>>>>> Looking forward to your thoughts on this. > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > >>>>>> Regards, > > > > > > > > > > > > > >>>>>> Aditya > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > >>>>>>>> On Jul 17, 2026, at 11:53, 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!vs-_AkY76KFOqYK02q4f2tKSkFdnly7eklb5qfewIk841seg2S5cIOXxFhnAixEYsDVuFQyJx8-D5g$ > > > > > > > > > > > > > >>>>>>> > > > > > > > > > > > > > >>>>>>> Thanks, > > > > > > > > > > > > > >>>>>>> Andrew > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
