Subject: #225: JFV Revisited

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Aug 2016 14:52:36 +1000

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)?

--
Mark Nottingham   https://www.mnot.net/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 11 Aug 2016 07:49:54 +0000

--------
In message <[email-masked]>, Mark Nottingham writes:
>For those not following the issues list closely, Ilya is wondering =
>whether browsers' implementation of ECMA-262 changes things for JFV:
>

<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
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Aug 2016 17:53:55 +1000

> On 11 Aug 2016, at 5:49 PM, Poul-Henning Kamp <[email-masked]> wrote:

>   future 100+Gbit/s speeds.

I'ts neither. The only thing we have broad agreement to, AFAICT, is

C) Specify conventions for people to use when defining headers, to avoid the most common footguns involved in that process (as well as generation, parsing, etc.).

There have been very few people who are excited about (A); rather, I think people saw JSON as a (somewhat distasteful, but practical) means to an end.  

You're the strongest proponent for (B); my perception (which I'm happy to have corrected) is that most others are happy to wait for an alternative encoding (e.g., in a future version of HTTP) to get the efficiency gains.

> Show of hands please...

That's not how things work, you know...

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 11 Aug 2016 08:21:00 +0000

--------
In message <[email-masked]>, Mark Nottingham writes:

>There have been very few people who are excited about (A); rather, I 
>think people saw JSON as a (somewhat distasteful, but practical) means 
>to an end.  

Yes, that's my perception as well, but does that imply that any
alternative to JSON stands a chance at the end of the day ?

Some of us learned that lesson with HTTP2, where "all options were
open (as long as they are based on SPDY)".

If people think the "common structure" brain-storm I floated have
enough merit, I'll be happy to try to turn it into an I-D so we can
take it from there.

But I dont want to waste my time, if there is a "sub rosae" requirement
for the result to be JSON?

>You're the strongest proponent for (B); my perception (which I'm happy 
>to have corrected) is that most others are happy to wait for an 
>alternative encoding (e.g., in a future version of HTTP) to get the 
>efficiency gains.

Yes, I think it is important that we keep (B) firmly in view.

I fully agree that we will not reap any big gains until we do
HTTP[3-6] with that focus, so we should be careful already now, to
not make that future task any harder than it needs to be(come).

Moores Law ran out of steam a few years ago, but we still need to
handle higher and higher concentrations of traffic[1], so we can no
longer just lean back and expect Intel to solve our future performance
problems.

Poul-Henning

[1] Btw: Yes, Google *does* use load-balancers, and yes, those
people are very much of the same sentiment, even though they did
not participate in the workshop.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Aug 2016 16:42:21 +1000

> Thoughts (here or there)?

I thought that the direction of the discussion was promising.  A
bespoke format, though more work, is entirely justified in this case.
I anticipate a draft-kamp-http-??? document in our near future that
collects up the best of the progress thus far.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 12 Aug 2016 19:03:11 +1200

> bespoke format, though more work, is entirely justified in this case.

Ditto. I was okay with JSON only for the short period where the Draft
was speaking of it as the format for use in RFCs (as replacement for
ABNF) not on-wire format for delivery.

What will be will be, but I wont pretend to like it (JSON). Even YAML
would be better than JSON, but that would require use of obs-fold.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Aug 2016 17:08:06 +0200

> ABNF) not on-wire format for delivery.

It never did that.

> ...

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 13 Aug 2016 04:53:16 +1200

On 13/08/2016 3:08 a.m., Julian Reschke wrote:
>>> On 11 August 2016 at 14:52, Mark Nottingham wrote:

Well the text in the pre- ietf'96 Draft certainly fooled me.

Amos

---

From: Ilya Grigorik <[email-masked]>
Date: Mon, 15 Aug 2016 17:20:18 -0700

On Thu, Aug 11, 2016 at 12:53 AM, Mark Nottingham <[email-masked]> wrote:

> C) Specify conventions for people to use when defining headers, to avoid
> the most common footguns involved in that process (as well as generation,
> parsing, etc.).... I think people saw JSON as a (... snip ... practical)
> means to an end.
>

^ yes, that.

> for the result to be JSON?

No, there isn't. But JSON, despite the downsides that have been brought up
here, *is* very appealing on a practical level.

I'd be more than happy to see viable alternative proposals that address all
of the above points.