Re: draft-ietf-httpbis-jfv: what's next

[Martin Thomson <[e-mail]>]

On 15 October 2016 at 20:41, Poul-Henning Kamp <[e-mail]> wrote:
> Looking forward, if we want to be able to use CS to build H3
> compression, we cannot allow CS headers with format errors.

I tend to agree with this, though there are levels of format errors.
For instance, if you use the >< notation and the < is absent, that's a
flat parse error (I would argue that the < is redundant actually, save
an octet).  But as you say, use of an unknown Content-Encoding is a
semantic-level failure that the parser can't be expected to handle.
Besides, we have to allow for extension in values, and that's hard.

But what I think that Matt is looking for is a grammar that supports
an in-band signal about type so that syntax checking can be done by
the parser (and not by the semantics layer).  That - to me - seems
like a pretty reasonable request.  That means that you get a level of
generic validation.  Based on what you have, you could reduce this to
string/number, but I think that you could be a tiny bit more
adventurous (and include date and binary for starters).

I agree that going any non-trivial distance down this path is a
crapshoot.  The need for rules - or at least any consistency - rapidly
evaporates.  But there is a modicum of value in being able to
distinguish type, if only to allow for the use of better types in that
datastructure you talk about.