Re: Mahesh Jethanandani's No Objection on draft-ietf-httpbis-no-vary-search-09: (with COMMENT)

Hi Mahesh,

Thanks for the comments!

I've added an explanatory sentence about the rationale behind the
relationship with "Cache-Control" in
https://github.com/httpwg/http-extensions/pull/3508.
We had updated the examples table based on the GENART review
<https://github.com/httpwg/http-extensions/pull/3502>, but I also included
an additional row with that specific example in the new PR above just to
avoid any confusion.

Please note that I didn't adjust the WHATWG references yet, since there's
an ongoing discussion
<https://lists.w3.org/Archives/Public/ietf-http-wg/2026JulSep/0183.html> on
that topic.

Best,
Nidhi Jaju

On Tue, Aug 18, 2026 at 4:16 AM Mahesh Jethanandani via Datatracker <
noreply@ietf.org> wrote:

> Mahesh Jethanandani has entered the following ballot position for
> draft-ietf-httpbis-no-vary-search-09: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-no-vary-search/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 7, Caching:
>
> 770 >    To reuse a stored response, Section 4 of [HTTP-CACHING] requires
> that
> 771 >    the presented target URI and that of the stored response match.
> If a
> 772 >    cache implements the No-Vary-Search extension, this matching
> 773 >    requirement is also satisfied if the URIs are equivalent modulo
> URL
> 774 >    variation config (Section 6) given the stored response's No-Vary-
> 775 >    Search header.
>
> I don't think this document can be silent on "Updates: 9111." Corey
> Bonnell raised exactly this in his SECDIR last-call review, and the
> shepherd write-up's answer to question 19 is "It is an extension to
> caching (RFC 9111) but does not strictly update it" -- asserted without
> much argument. Nidhi's response to Corey on-list was that a new header
> field is a well-established extension mechanism that doesn't need the
> tag. I don't think that holds up against what RFC 9111 itself says. Its
> Section 4 states that "a cache extension can override any of the
> requirements listed; see Section 5.2.3," and Section 5.2.3 defines "cache
> extension" specifically as a Cache-Control directive, not an arbitrary new
> response header field. No-Vary-Search doesn't use that mechanism; it
> changes the Section 4 matching condition from outside it.
>
> Julian Reschke raised the identical question during WGLC ("Cache-Control
> vs new header field," January 2026), pointing at the same Section 4/5.2.3
> text and asking why this wasn't defined as a Cache-Control directive. He
> concluded the WG probably wouldn't change course at that point, but asked
> that the document "minimally mention this as a design choice/
> consideration." I don't see that it did -- "Cache-Control" doesn't appear
> anywhere in the current text.
>
> I'm not asking the working group to redesign the field this late. But I'd
> ask the authors either to add "Updates: 9111," or to add a sentence
> explaining why they consider this outside the extension point that RFC
> 9111 itself defines.
>
> ---
>
> Section 11.1, Normative References:
>
> 1083 > [WHATWG-ENCODING]
> 1084 >            van Kesteren, A., "Encoding Living Standard", 21 May
> 2026,
> 1085 >            <https://encoding.spec.whatwg.org/>.  WHATWG
>
> I support Deb Cooley's and Roman Danyliw's comments on the
> WHATWG references. encoding.spec.whatwg.org doesn't serve a "21 May 2026"
> snapshot at that URL once the living standard has moved on, so a reader
> who wants the exact text this RFC was written against has no way to
> retrieve it. The shepherd write-up flags this too (Q14,
> Q15, Q17), explicitly leaving it for the IESG to judge whether these four
> WHATWG references are appropriate as normative, downward references. I'd
> like to see that judgment actually made rather than left open. Either
> point to an archived/pinned copy of each of the three WHATWG documents
> (a W3C TR-style snapshot or a web archive capture would both work), or
> explain why the working group believes a bare date is sufficient.
>
> ----------------------------------------------------------------------
> NIT
> ----------------------------------------------------------------------
>
> All comments below are about very minor potential issues that you may
> choose to address in some way - or ignore - as you see fit. Some were
> flagged by automated tools (via
> https://github.com/larseggert/ietf-reviewtool), so there will likely
> be some false positives. There is no need to let me know what you did
> with these suggestions.
>
> Section 5.2.1, Table 1:
>
> 415 >             +=================+==============================+
> 416 >             | Input           | Result                       |
> 417 >             +=================+==============================+
> 418 >             | No-Vary-Search: | no-vary params: (empty list) |
> 419 >             | key-order       | vary params: *wildcard*      |
> 420 >             |                 | vary on key order: false     |
> 421 >             +-----------------+------------------------------+
>
> Mallory Knodel's Gen-ART review asked for the positive/explicit form
> "key-order=?1" to be added here alongside the shorthand "key-order," for
> completeness against Table 3, which shows the two as equivalent. That
> still isn't in the table.
>
>
>