- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 2 Mar 2020 13:57:15 +1100
- To: Jeffrey Yasskin <jyasskin@google.com>
- Cc: Yoav Weiss <yoav@yoav.ws>, "Julian F. Reschke" <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, Tommy Pauly <tpauly@apple.com>
Yes, I think that makes sense. The reason for adding this was to make sure that CH authors understood that they'd see better cache efficiency if they did this, but it's not ready yet. > On 29 Feb 2020, at 7:23 am, Jeffrey Yasskin <jyasskin@google.com> wrote: > > On Thu, Feb 27, 2020 at 2:28 AM Yoav Weiss <yoav@yoav.ws> wrote: > The PR is now merged and addresses most of the comments. > > > Appendix A. Interaction with Variants Response Header Field > > Client Hints may be combined with Variants response header field > [VARIANTS] to enable fine-grained control of the cache key for > improved cache efficiency. Features that define Client Hints will > need to specify the related variants algorithms as described in > Section 6 of [VARIANTS]. > > Unless we're planning to finish VARIANTS really soon, I'd drop this > appendix. > > mnot - thoughts? > > Friendly ping! :) > > I might have been involved in asking for this section... Basically, if this document is ready to go to RFC before Variants, we don't want to artificially block it behind Variants, which this Appendix would do. To fix that, this text ought to move to https://tools.ietf.org/html/draft-ietf-httpbis-variants-06#appendix-A. > > If Variants had gone first, this text would be in the right place, for the same reason. > > That is, I agree with Julian. > > Does that make sense? > > Jeffrey -- Mark Nottingham https://www.mnot.net/
Received on Monday, 2 March 2020 02:57:37 UTC