Before we do that, I'd like to get #164 done.

At the end of the day, we need to decide what the ABNF in general and the collected ABNF in particular are for.

My understanding was that we have the ABNF to guide people to write sane parsers, and have additional prose putting constraints on top. Putting the constraints into the grammar makes it useless for deriving parsers.

I think #211 is gathering data that will help this decision.

So, #164 done.

#211 showed that there aren't very many cases of really big prose requirements on top of ABNF (thankfully).

So, I think we're down to the original question; is ABNF for showing people how to write sane parsers, or what the "ideal" wire form is like?

Given the differences between the ABNF and what real-world parsers need to do to handle the Web (as evidenced by #128 -- and I think that's just the tip of the iceberg), I'd be more comfortable saying that it's for generation.

If we want it to be used for parsing, we'd need to a) convince people to actually use it to build their parsers (which they don't seem to want to do, largely), and b) align the ABNF with the reality of how those parsers work, -or- convince people to change their parsers to align with the ABNF (which I don't think is realistic).

I agree that it should be for generation, but it is also for what a recipient must accept for interop (e.g. obs-date):

https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#http.date

Do we have a short way of saying both?

Discussed; agreed to switch collected ABNF to sender version (currently in 4.5.1).

(still need to check new Vary expansion)