Re: #225: JFV Revisited

["Poul-Henning Kamp" <[e-mail]>]

--------
In message <[e-mail]>, Mark Nottingham writes:
>For those not following the issues list closely, Ilya is wondering =
>whether browsers' implementation of ECMA-262 changes things for JFV:
>
>  https://github.com/httpwg/http-extensions/issues/225
>
>Thoughts (here or there)?

<RANT>

  "it's not clear if and when such a format will come either…"

Please!

Can we stop the "WE NEED IT YESTERDAY!!" insanity and spend the
tiny amount of extra time it takes to not do half-assed jobs ?

At the workshop we heard a litany of "ohh..." regrets about H2, the
majority of which were raised before ratification, but steam-rolled
over because "we don't have time for that!"

There will not be any relevant or significant difference in how
long time it would take to get a header-JSON RFC out compared to
one based on my "common structure" brain-storming or for that matter
any third candidate starting from some other point:  The thing which
takes time is for people to pay attention and make up their mind,
not the actual writing and implementation work.

</RANT>

With that out of the way, I am still struggling to find out what
problem we are trying to solve here?

Is it:

A) Allow people to use (restricted) JSON in headers, because people
   want to use JSON in headers (and will do it anyway).

Or is it:

B) Try to make headers more compute-efficient in preparation for
   future 100+Gbit/s speeds.

Or is it both ?

If it is only A), then we just need to pick a restricted JSON syntax.

(Of course we all know that the restrictions will be ignored in
practice:  "If it looks like JSON and it parses like JSON..." so
it is not entirely obvious that the restrictions are really worth
much effort on our part.)

If A) is not a hard requirement, then we should ditch JSON,
which is a square peg for many of our round holes, and instead
do something along the lines of my "common structure" brain-storm,
where we generalizes existing syntax and thus simplify things,
instead of adding yet another parser with pre-known issues.

We can of course have both, but that means we have to think much
harder about where we allow JSON and be more restrictive about the
JSON subsetting than we would need to in the A-only case.

So it seems to me that the question we need to settle is:

  Is being (a subset of) JSON a hard requirement ?

I vote "No".

Show of hands please...

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[e-mail]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.