Code change:
received, it will by default be ignored.  If the header requires different error handling, this should be explicitly specified. <del> However, both Items and Inner Lists allow parameters as an </del> <ins> However, both items and inner lists allow parameters as an </ins> extensibility mechanism; this means that values can later be extended to accommodate more information, if need be.  As a result, header specifications are discouraged from defining the presence of an unrecognised parameter as an error condition. <del> Conversely, inner lists are only valid when a header definition explicitly allows them. </del> <ins> To help assure that this extensibility is available in the future, and to encourage consumers to use a fully capable Structured Headers parser, a header definition can specify that "grease" parameters be added by senders.  For example, a specification could stipulate that all parameters beginning with the letter 'q' are reserved for this use. </ins> Note that a header field definition cannot relax the requirements of this specification because doing so would preclude handling by

Related discussion:
text: NAME Fetch Metadata will add a bunch of headers that are supposedly structured headers, but given their simplicity can be compared using equality on servers. If servers did that it would likely prevent adding parameters in the future however or making other supposedly-compatible extensions. Should we accept this for headers clients transmit to servers or should we do something akin to TLS's GREASE?
In general, greasing HTTP headers is interesting -- although I'm a little wary, given the extent of the grease-related discussions we've had in QUIC. As a baseline -- I think that the goal of grease should be to prevent casually incomplete implementation (e.g., someone using regex or splitting on commas and extracting the raw values). It can never assure complete and correct implementation overall. I think the interesting thing to grease in SH is parameters, since that's a primary extensibility mechanism, and is (now) uniform across values. Ideally, grease parameters would contain values that frustrate the casual approaches above; e.g., strings with commas in them. A couple of options I can see; We could advise / require sending implementations to generate extra parameters sporadically (not super-often, so as to limit bandwidth consumption, but not so rarely that it creates debugging nightmares). To be recognisable as grease to the receiving application, their names would have to have some convention. We could advise / require headers using SH to define their own greasing mechanisms when appropriate. I suspect that truly automatic greasing might increase friction against adoption of SH, since some people's reaction will be "what is this thing doing to my header?!?". Invoking in on a header-by-header basis (perhaps by adding an appendix with guidance) might help.
I think the main benefit is derived from clients doing this so the main party to convince would be the user agents (who are already generally on board with SH).
So, should anything in the spec change? At this point the most I can see is adding something like:
I guess I'm mainly interested if implementations are willing to do this uniformly. NAME NAME NAME
I think NAME suggestion is reasonable to recommend (though it risks a quagmire when we attempt to ship a new header defining a quotient of quietly quixotic quilting), but I'll defer to NAME or NAME to weigh in from Chromium's networking team's broader perspective for headers generally.