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

On 15 October 2016 at 20:41, Poul-Henning Kamp <phk@phk.freebsd.dk> 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.

Received on Saturday, 15 October 2016 09:58:57 UTC