Re: Fwd: New Version Notification for draft-nottingham-structured-headers-00.txt

On 10/29/2017 06:57 PM, Mark Nottingham wrote:
>   https://mnot.github.io/I-D/structured-headers/

> * Is the parsing too strict, not strict enough, or just right?

AFAICT, the top-level parsing algorithm in Section 3 is missing a
catch-all rule for trailing garbage. For example, right now, the
following malformed Item header field will pass all checks and return a
"valid" String to the caller. It should throw a "trailing garbage" error
instead.

  Foo: "valid" garbage!

When fixing that, tolerating trailing BWS may be a good idea.


> Note that input_string may incorporate multiple header lines combined
> into one comma-separated field-value

I understand the desire to limit this specification to parsing a single
header field or equivalent, leaving the Pandora box of combining
same-name fields closed. However, this honorable approach complicates
placing interoperability limits on the number of list members: An
application that parses individual fields (and possibly never combines
the results!) may not hit the limit that an application combining raw
value strings before parsing would hit.

IMHO, we should explicitly say something (conservative) about this
problem so that header generators know how the limits may be applied.


> However, field definitions are encouraged to clearly state additional
> constraints upon the syntax, as well as the consequences when those
> constraints are violated.

I would rephrase that phrase to avoid a misunderstanding: That phrase is
talking about additional _semantic_ restrictions (on top of the frozen
syntax rules), not additional syntax constraints.


Not sure whether this is in your "interesting things to discuss" scope,
but please allow empty quoted strings :-).


Thank you,

Alex.
P.S. I am not reporting individual BNF and algorithm problems because
they seem to be outside the "interesting things to discuss" scope.

Received on Monday, 30 October 2017 22:25:12 UTC