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

[Tommy Pauly <[e-mail]>]

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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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