I don't see how this is going work.

If this is data the backend needs the client is either going to have to send it out on every request (like it does today with the User-Agent header) - or the client will only send it out once, and the response would be cached by the backend somehow. The requirement to cache this data on the backend is non-trivial to implement and is a huge paradigm shift. That's actually another pitfall with the RFC in a sense.

> It doesn't commit the exact same info though. This says "the client is aware of this scheme and doesn't reply, vs the client is unaware of the rfc. It's the true/false/none issue."

This doesn't make any sense to me whatsoever.

The "scheme" is what we make it out to be. If the scheme would allow for omitting headers (as it should have) - then the client would be in compliance with the scheme, wouldn't it?

By designing an RFC which allows for omitting headers we actually resolve the ambiguity between "false" and "none": the data is either explicitly there, or it's not.

I'm simply claiming that the scheme as currently proposed is nonsensical and negligent. At Chrome's scale - I expect each proposal to introduce more headers and data to every request to be very carefully weighed against impact on global bandwidth consumption and resource utilization (and energy use). I don't feel like any of that is reflected in this RFC, which is an absolute shame and a big part of the problem: we keep piling up more crap thinking "it doesn't really make a difference". I think it reflects poorly on the people involved with designing and building this.

Perhaps we should mandate providing these numbers explicitly with every RFC so that we can know how much the implementation actually "costs" in terms of bandwidth, memory, etc at the web's scale. This should help identify RFCs like this one which are seriously off on the engineering side of things.