- From: Carsten Bormann <cabo@tzi.org>
- Date: Mon, 01 Aug 2016 10:33:22 +0200
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Hi Poul, (I'm only lurking in this WG because the HTTP protocols are useful for certain IoT applications; however I do understand the design focus here is more on browser-web/big-web applications.) Poul-Henning Kamp wrote: > My personal intuition was that we should find a binary serialization > (like CORS), I'm assuming here you mean CBOR? > and base64 it into HTTP1-2: Ie: design for the future > and shoe-horn into the present. But no obvious binary serialization > seems to exist, CORS was panned by a number of people in the WS as > too complicated, (If you are talking about CBOR:) Well, it is more complicated than doing nothing. Once a bespoke design of a data model and serialization is completed, that is likely to be as complicated as CBOR (or even more). The real problem is then that we have added another data model and serialization of that data model to the overall complexity that needs to be managed by a system that connects to the web. (That may not make a difference for a browser, but it does for IoT and other machine-to-machine applications.) The specific data model that you have designed looks fine to me; it should be representable in CBOR without problem. What remains is the cognitive dissonance of having done a base64(url) transformation, but as you say that is not a real technical problem with HPACK. (I am aware of the debugging advantages of text encoding, but these are values that go into HTTP/2 headers and are obscured by HPACK, anyway.) > and gag-reflexes were triggered by ASN.1. I do sympathize here :-) Grüße, Carsten
Received on Monday, 1 August 2016 08:36:07 UTC