I'm working on the impact of CVE-2019-9636 as part of my day-job.
I'd be interesting in your analysis of how you parsing proposal would have avoided this problem before it was described.
I add the "before it was described" because I think you are claiming that the universal parser will prevent this class of
security issue by the nature of its design.
That's exactly what I'd like the list to consider.
I claim that a parsing library would prevent this class of issues simply because it follows the specification to the letter.
Is the specification complete and unambiguous? Too often there are gaps in a specifications that go unnoticed and lead the problems.
Was the specification updated but the code to match it was not?
While a parsing library may, or may not, make an implementation easier to write and review there is still room for human error.
Mistakes in understanding a specification are made by engineers and lead to problems that sometimes take years to discover.
In short I think this may reduce problems, but "prevent" them I do not believe.
As you'll find in my code, the grammar is trivial translation of what is in the spec, one for one. Not only will this help explain what the code is doing, but also raise the confidence that the code matches the spec.
I'm happy to have better tools and making review easier. Of course the parser needs to have a specification, documentation and trusted implementation to get the benefits.
Full disclosure, I fixed bpo30500, but I was not at all confident that the fix was correct. I understood what the code did; I just couldn't tell if that was the right thing to do.