Hi Luke, Thanks for your response. LC1: Good point. I think that we should limit the lengths of the config keys for sure. I have updated the KIP accordingly, but this one is perhaps a bit more nuanced because config key names are sometimes created using concatenation (think producer configs in Kafka Connect for example, or configs containing listener names). I expect there will be debate on this one. 249 is pretty generous though, I feel.
For the config values, I am more relaxed about allowing longer values except for the cases I called out. For example, SASL config can be quite long and contain embedded strings. I know that's a client config, but clients in the broker use these configs too. I've not restricted config values at this point beyond the existing 32kB. Happy to debate more. LC2: Posix path names are restricted to 260 characters, so I think that provides an obvious candidate limit. LC3: Good point. I've updated the KIP for this too. I think it's an interesting point to limit all strings unless specifically loosened or tightened. I haven't done that yet. Let's see if there are comments from other community members and see if there's a consensus. Thanks, Andrew On 2026/06/11 10:06:40 Luke Chen wrote: > Hi Andrew, > > Thanks for the KIP. > I agree we should tighten the rules for the protocol to limit the > complexity and size of requests and responses. > > LC1: From the table, I think we also need to add: > 1. IncrementalAlterConfigsRequest > 2. AlterConfigsRequest > because we allow users to add/update any config name/value to the broker. > > LC2: In AlterReplicaLogDirsRequest, we allow users to set the path, should > we also limit it? > > LC3: In AlterUserScramCredentialsRequest, we allow users to set a random > scram name. > > I'm thinking if we should directly limit all String fields to size 249 > directly? And consider loosening or tightening the rule for specific > fields, like "Group member ID" and "Offset commit metadata"? > > Thank you, > Luke > > On Tue, Nov 25, 2025 at 9:49 AM Kirk True <[email protected]> wrote: > > > Hi Andrew, > > > > As proposed, I don't think there's a straightforward way to log warnings > > that won't require knowledge of the broker's enforcement status. > > Ultimately, the cluster administrators have the option of setting > > resource.identifier.limit.enable back to false in a "break glass" situation. > > > > Thanks, > > Kirk > > > > On Tue, Nov 4, 2025, at 2:02 AM, Andrew Schofield wrote: > > > Hi Kirk, > > > Thanks for reviewing the KIP. > > > > > > KT1: I suppose one way would be to issue a warning log in the client if > > the user attempts to use identifiers longer than the KIP recommends. We > > could even make it conditional on the version of the requests being built > > so that the “proper” exception is thrown instead if the broker supports the > > bumped versions of the APIs which support the new error code. I don’t think > > we should pander too much to these people. Wdyt? > > > > > > Thanks, > > > Andrew > > > > > > > On 4 Nov 2025, at 01:36, Kirk True <[email protected]> wrote: > > > > > > > > Hi Andrew, > > > > > > > > Thanks for the KIP. I like the idea of standardizing the resource ID > > lengths and largely agree that—to paraphrase an apocryphal quote—no one > > will ever need more than 249 characters. > > > > > > > > KT1: My understanding is that the client will be ignorant of the > > limits, up until the point the server returns the > > "RESOURCE_IDENTIFIER_TOO_LARGE" error. I worry that for (the small number > > of) users whose IDs violate these limits, their applications will work one > > day, and then unexpectedly break the next. Ideally there would be a grace > > period in which to warn users that they're over the limits so they can make > > changes before the limits are enforced. Warning logs could be added on the > > broker side, but that information may not make it to an organization's > > individual applications because it's not always easy to correlate the > > warnings to a particular application. > > > > > > > > Thanks, > > > > Kirk > > > > > > > > On Sun, Nov 2, 2025, at 4:22 AM, Andrew Schofield wrote: > > > >> Hi, > > > >> I’d like to start discussion on KIP-1233: Maximum lengths for > > resource names and IDs. > > > >> > > > >> Today, Kafka applies a limit of 249 characters for topic names, but > > other identifiers such > > > >> as group IDs do not have limits. The KIP proposes introducing limits > > for all resource > > > >> names and identifiers in Apache Kafka 5.0. The proposed limits are > > intended to be large > > > >> enough that nobody is impacted. > > > >> > > > >> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1233%3A+Maximum+lengths+for+resource+names+and+IDs > > > >> > > > >> Thanks, > > > >> Andrew > > > >> > > > > > > > > >
