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

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 <tpauly@apple.com> 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 <rory.hewitt@gmail.com> 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 <
> gs-lists-ietf-http-wg@gluelogic.com> 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 <internet-drafts@ietf.org> 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