[fenollp]

While this seems good to have a more efficient transport, I can't make sense of this

    > Since the subsequent IETF drafts 30 and 31 do not have compatibility-breaking changes, we currently are not planning to change the over-the-wire identifier.

Are there slow-moving internal software at Google that relies on this nonce? This looks like the kind of thing that some clients will tend to rely on (for a reason yet unknown). That's how clients grow the standard in unintended ways, no?

On another note:

    3.  optionally, the trailer field section, if present, sent as a single HEADERS frame.

I see you're paving the way for gRPC on the Web (of browsers) by adding trailers (a header sent after the body), which is not supported today for HTTP/1 not /2 by at least the top 3 browser vendors in volume.

I'm divided: I'd be glad to get rid of grpc-gateway and websockets but isn't proto-encoded communication bad for the open Web /in principle/? Maybe it's only a tooling problem.

[gravypod]

I think there's a large volume of tools that can be built that will make things much more discoverable as we go along this route. Things like the gRPC reflection, health checks, etc can all be instrumented in tooling with no guess work as to how to directly talk to any API that implements it. No guessing if it's `GET /healthz` or `GET /healthcheck` etc.

There's a lot of magic you can do with protos. At my current company we're even generating forms/UIs entirely off of proto message definitions for things like configs. Engineers no longer need to think about how to make something work cross language, manually wiring up a UI, etc.

I cant wait to see what doors this opens up for gRPC on the browser as that will bring many more OSS devs into the ecosystem.