Re: Permitted characters in HTTP/2 fields

Cory et al,
In totally ok with the principle of be strict in what you generated and
relaxed in what you accept.

I understand the effort here is to try to tighten up that relaxed
acceptance a bit to ensure that security issues are not created as a
result, but not to impose strict requirement for full Field ABNF compliance.

I just find the text is too imprecise and the motivations for it are not
sufficiently well capture either in the text itself or the PR. It may be
clear to those that attended the meeting, but I find there is missing
context.

If we want to allow flexibility but avoid security issue than we need text
that says: implementations SHOULD (or MAY) enforce the full ABNF ; in order
to avoid security issues [insert ref] all implementation MUST NOT send or
accept fields with <insert precise definition here>.

There is now some discussion on exactly what characters should be
allowed/rejected. Clearly starting exactly the security issues that are
being avoided should assist with well defining that set.