Re: I-D Action: draft-ietf-httpbis-no-vary-search-05.txt

[Nidhi Jaju <[e-mail]>]

Hi,

I agree with Tommy that renaming params/except to include/exclude is an
editorial change. The parsing and processing logic is unchanged, so what
we're discussing is which strings sit on the wire.

Each of the proposals has pros and cons. include/exclude reads more
naturally on its own, but as noted, "exclude" inside a field called
"No-Vary" is confusing depending on how you parse the field name, since the
things that are excluded are the ones that don't vary. Cache-Query-Params
came up as an option to replace No-Vary-Search, but it's not clear that
there's a significant enough win to justify a rename at this point.

It seems to me that the alternatives are not meaningfully better enough to
warrant changing it everywhere, and I don't see the WG solidifying around
any particular option. In the absence of a clear improvement, I think
keeping the current names and capturing the discussion in the shepherd
writeup makes sense.

Best,
Nidhi

On Tue, Jun 2, 2026 at 11:49 AM Tommy Pauly <[e-mail]> wrote:

> Hi Rory,
>
> Thanks for clarifying your concern here. I do read this still as an
> editorial comment, not necessarily around the format. As defined in the
> draft, the parameters that do no vary the search are "No-Vary-Search:
> params=(…)”, and if all parameters do not vary the search except for some,
> those are specified as "No-Vary-Search: except=(…)”. From the issue
> discussion and here, you are suggesting to rename “params” to “exclude” and
> “except” to “include”. This doesn’t change the parsing or processing logic,
> but just changes the strings. As such, this seems, like the overall field
> name, a primarily editorial topic that is getting into bike-shedding.
> (Additionally, now speaking as an individual, the comprehensibility aspect
> seems somewhat subjective here; since the field name is *no-*vary, having
> “*exclude*” be the items that are *included* in the set of items that do
> not vary can also get confusing.)
>
> As I mentioned in my last email, I’ll plan to progress this document and
> note the comments about the name and terminology in the field. I’ll plan to
> do this at the end of the week, unless I see more discussion that shows the
> WG moving to consensus around some particular change.
>
> Thanks,
> Tommy
>
>
> On May 18, 2026, at 9:58 AM, Rory Hewitt <[e-mail]> wrote:
>
> Hey Tommy,
>
> Yes and no.
>
> Issue 3287 was opened for a specific point (removing an empty 'params'),
> but there was a lot of subsequent discussion on that Issue thread around
> field format simplification, and also around changing the field name. Then
> PR 3374 happened, which addressed the original point from Issue 3287, but
> didn't address any of the subsequent discussion. I saw your comment at the
> end of that thread referring to much of that discussion as 'editorial', but
> I don't think you are correct - several people who commented (myself,
> Martin, even Mark and Nidhi) agreed that actually 'include/exclude' is
> clearer that 'params/except'. and other additional folks, including Julian,
> thought a name change might also be good.
>
> To be clear, while I'm not particularly a fan of the current field name,
> my primary concern is around the field format - I would strongly prefer to
> see 'include/exclude' rather than 'params/except', for comprehensibility by
> end-users. The reason I didn't open a separate issue is that I believed any
> PR created off that issue would (potentially) look at all the discussions
> on the issue.
>
> Rory
>
>
> On Thu, May 14, 2026 at 9:08 PM Tommy Pauly <[e-mail]> wrote:
>
>> Hi Rory, Glenn,
>>
>> Thanks for the conversation here! Sharing my interpretation here for how
>> to move forward.
>>
>> Regarding the issue (
>> https://github.com/httpwg/http-extensions/issues/3287) that issue was
>> about simplifying the structured field definition, which resulted in the PR
>> made here (https://github.com/httpwg/http-extensions/pull/3374) That
>> change was a substantive change that got review and support.
>>
>> The issue also contains a fair amount of discussion about other possible
>> names for the field. The WG can absolutely decide to change the name, and
>> we can absolutely make late name changes — however, I’d like to see a very
>> clear consensus around a particular name if we’re to go down that road. As
>> noted in the issue, this is getting into bike-shedding for a document that
>> is late in the process, for which there has been discussion on the name
>> previously. The issue links to history on discussion both before it came to
>> the IETF and this group, as well as on the list. I read this as a mix of
>> people where some like the current name and some don’t like it, with
>> arguments on both sides.
>>
>> On the issue in question above, I had closed it with the comment that the
>> issue itself was addressed by the PR, and that further discussion can be
>> separate. Given that I didn’t see new issues filed to concretely propose a
>> name change, and we didn’t get any WGLC feedback to the list regarding
>> needing a name change, my current preference is to note the discussion
>> about the name in the shepherd writeup for the document, but otherwise
>> progress it. Of course, if there is some clear shift where the working
>> group agrees on a different name, then we can and will absolutely follow
>> that.
>>
>> Thanks,
>> Tommy
>>
>> On May 14, 2026, at 1:47 PM, Rory Hewitt <[e-mail]> wrote:
>>
>> I agree that the field name isn't great, but I honestly do hesitate to
>> cause trouble.
>>
>> As I said in that GitHub comment thread, "I'm not a huge fan of either
>> No-Vary-Query or No-Vary-Search - I would probably have gone with
>> Cache-Query-Params or something similar to emphasize that this is all
>> about defining *which* query parameters should be used (and *how*, in
>> the case of ordering) for browser caching."
>>
>> On Thu, May 14, 2026 at 12:10 PM Glenn Strauss <
>> [e-mail]> wrote:
>>
>>> I previously commented that "No-" is jarring and causes friction.
>>> It does not belong.
>>>
>>> If "Vary-Search" or something similar, then a syntax could easily be
>>> defined for inclusion sets and exclusion sets.  "No-Vary-Search" is
>>> less clear, less flexible, and less extensible.
>>>
>>> Cheers, Glenn
>>>
>>> On Thu, May 14, 2026 at 10:39:35AM -0700, Rory Hewitt wrote:
>>> > We had some discussion back in Jan/Feb in the GitHub repo (
>>> > https://github.com/httpwg/http-extensions/issues/3287) about
>>> simplifying
>>> > the SF field format for this, and even changing the field name itself.
>>> Is
>>> > that definitely not going to happen?
>>> >
>>> > I swear (as I swore then) that bikeshedding is not my intent, but as
>>> Martin
>>> > T responded then, "naming is hard, but I've seen late name changes work
>>> > very nicely.", and Julian R seemed to agree.
>>> >
>>> > On Tue, May 12, 2026 at 10:45 PM <[e-mail]> wrote:
>>> >
>>> > > Internet-Draft draft-ietf-httpbis-no-vary-search-05.txt is now
>>> available.
>>> > > It
>>> > > is a work item of the HTTP (HTTPBIS) WG of the IETF.
>>> > >
>>> > >    Title:   The No-Vary-Search HTTP Caching Extension
>>> > >    Authors: Domenic Denicola
>>> > >             Jeremy Roman
>>> > >             Nidhi Jaju
>>> > >    Name:    draft-ietf-httpbis-no-vary-search-05.txt
>>> > >    Pages:   18
>>> > >    Dates:   2026-05-12
>>> > >
>>> > > Abstract:
>>> > >
>>> > >    This specification defines an extension to HTTP Caching, changing
>>> how
>>> > >    URI query parameters impact caching.
>>> > >
>>> > > The IETF datatracker status page for this Internet-Draft is:
>>> > > https://datatracker.ietf.org/doc/draft-ietf-httpbis-no-vary-search/
>>> > >
>>> > > There is also an HTML version available at:
>>> > >
>>> https://www.ietf.org/archive/id/draft-ietf-httpbis-no-vary-search-05.html
>>> > >
>>> > > A diff from the previous version is available at:
>>> > >
>>> > >
>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-httpbis-no-vary-search-05
>>> > >
>>> > > Internet-Drafts are also available by rsync at:
>>> > > rsync.ietf.org::internet-drafts
>>> > >
>>> > >
>>> > >
>>> > >
>>> >
>>> > --
>>> > Rory Hewitt
>>> >
>>> > https://www.linkedin.com/in/roryhewitt
>>>
>>
>>
>> --
>> Rory Hewitt
>>
>> https://www.linkedin.com/in/roryhewitt
>>
>>
>>
>
> --
> Rory Hewitt
>
> https://www.linkedin.com/in/roryhewitt
>
>