[secdir] Re: draft-ietf-httpbis-no-vary-search-06 ietf last call Secdir review

[Nidhi Jaju <[e-mail]>]

On Tue, Jul 28, 2026 at 10:36 PM Corey Bonnell <[e-mail]> wrote:

> Hi Nidhi,
> Thanks for the PR. I reviewed and have two follow-up items for your
> consideration:
>
>
>    1. If a key name in No-Vary-Search is a percent-encoded string
>    normalized using NFD but the actual URI presents the query param as
>    normalized using NFC, what is behavior? I assume they will not match
>    (assuming there's at least one code point that encodes differently under
>    the two normalization forms), but it is worth being explicit on the
>    expectation here.
>
> Added a note in the PR clarifying that no Unicode normalization is
performed during comparison, so strings like ?a=é (NFC) and ?a=é (NFD)
will not match.

>
>    1. I think this draft needs to update RFC 9110 given the change in
>    normative guidance in section 7.
>
> Given that this document is using a well-established extension mechanism
for HTTP in the form of a new header field, I don't think that we usually
mark every new header field that adjusts implementation behaviors as
updating the main HTTP semantics document (RFC 9110).

This aligns with https://wiki.ietf.org/group/iesg/useofupdatestag, although
that draft didn't achieve sufficient consensus to ever be posted. The part
about "Normative updates that do not use a known extension point should
always include an “Updates” header. Extensions that do use known extension
points do not typically need to include the “Updates” header" seems to
align with current practice. This is an extension using an extremely
commonly used extension point that implementers of HTTP semantics don't
need to be aware of unless they also support the new extension indicated by
the header field.

In case you meant RFC 9111 (HTTP Caching): You're right that an earlier
draft of Section 7 explicitly "replaced" normative text from Section 4 of
RFC 9111. However, based on your earlier feedback, I actually rewrote
Section 7 in the PR to remove that normative replacement language. It now
simply states that if a cache chooses to implement this extension, the RFC
9111 matching requirement is also satisfied.

Best,
Nidhi


> Thanks,
> Corey
>
>
>
> Jul 28, 2026, 04:18 by [e-mail]:
>
> Hi Corey,
>
> Thank you for the review. I've uploaded a PR to address the comments here:
> https://github.com/httpwg/http-extensions/pull/3500.
> Please let me know if you have any additional feedback.
>
> Best regards,
> Nidhi Jaju
>
> On Thu, Jul 23, 2026 at 6:48 PM Julian Reschke <[e-mail]>
> wrote:
>
> Am 22.07.2026 um 19:51 schrieb Corey Bonnell via Datatracker:
> > ...
> > A few other comments outside the Security Considerations:
> > 1. Since Section 7 of this document replaces text in Section 4 of RFC
> 9111, I
> > would expect that this document updates RFC 9111. 2. Section 5.3 scopes
> the
> > algorithm to ASCII inputs ("To parse a key given an ASCII string
> keyString:"),
> > but the examples in 5.3.1 all contain non-ASCII code points.
> > ...
>
> 1) "Extends" would be less concerning. From this perspective, using an
> actual extension point would be great; but that point would be
> "Cache-Control". There are lots of components that fail for complex
> field values (right?), but maybe this would be a reason for developers
> to actually fix their code.
>
> Also, maybe it would be better if the change would be as self-contained
> as possible, such as just re-defining what "matching" means (that
> wouldn't require to patch the actual algorithm. Maybe a caching expert
> could chime in? Mark? Willy?
>
> 2. On the HTTP layer, this is all ASCII. Non-ASCII comes in only when
> things are passed up to the UA. Maybe this needs some clarification.
>
>
> Thanks for the suggestions, Julian. I've included these in the PR above.
>
>
>
> Best regards, Julian
>
>
>
>