Re: The use of binary data in any part of HTTP 2.0 is not good

[Eliot Lear <[e-mail]>]

Let's separate the general case from this one.  In the general case,
interoperability can be helped with text you don't need a library to
interact the other endpoint.  You just need fingers and telnet.  To
underestimate that value is to I think misunderstand the history of some
of our success.  Early movement to ASN.1 for so-called ease of parsing
by computers and performance led to practically a SINGULAR
implementation of the encode/decode rules, which in turn led to a
horrendous security mess in 2002.

HTTP may require compression and performance improvement; we'll see, I
suppose.  Certainly it's vastly more complex than SMTP, requiring not
just a simple capabilities exchange and then a transaction, but quite a
bit more interpretation of results by both parties.  The struggle we
have before us is whether the ecosystem can or should move over, based
on such a low level change.  If it leads to a small number of encoders
and decoders, surely that would be bad.

Eliot


On 1/21/13 12:47 AM, Roberto Peon wrote:
>
> Text formats are, surprisingly, not easier to debug in my experience.
>
> Admittedly, they only require a text editor to examine, but, for a
> binary protocol, that is easy to remedy with a short utility. The
> ambiguity of how to parse that text format, however makes this
> examination more time consuming and error prone.
>
> In terms of total complexity, binary framed protocols are often far
> simpler, and thus more robust. In terms of total lines of code, a
> binary framer plus utility to present the data in human readable
> format is still less complex and smaller than most text framed
> protocols. In terms of CPU consumption, binary framed protocols are
> often faster.
>
> If you'd like to make a fast http parser, I'm happy to give you a
> binary framed version which will be significantly faster, smaller in
> lines of code, and more memory efficient.
>
> -=R
>
> On Jan 20, 2013 3:26 PM, "Tim Bray" <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Would it be possible to be data-driven?  Textual formats are
>     well-known to be easier to debug; but clearly, if there’s a
>     substantial performance benefit to going all-binary, so be it. So what
>     is the advantage, quantitatively? -T
>
>     On Sun, Jan 20, 2013 at 3:04 PM, Mark Nottingham <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     > In one of our recent meetings, one of the grey-bearded IETF
>     old-timers (I forget which, sorry) said that a textual-protocol
>     was a nice-to-have, but that it shouldn't be a determining factor
>     in design.
>     >
>     > I.e., if you can get everything you need out of a protocol,
>     *and* make it textual, do so, but if it detracts from the value
>     you get from it, don't let that constrain you.
>     >
>     > FWIW, I think that's a good rule of thumb. However, this means
>     that the community is going to need *excellent* tooling for
>     analysing, debugging, etc. HTTP traffic; and I don't just mean a
>     Wireshark plugin!
>     >
>     > Cheers,
>     >
>     >
>     > On 21/01/2013, at 9:36 AM, William Chan (陈智昌)
>     <[e-mail] <mailto:[e-mail]>> wrote:
>     >
>     >> There are many advantages to using binary data. If you would like a
>     >> textual representation of a protocol, I advise using a utility to
>     >> generate one for you.
>     >>
>     >> On Sun, Jan 20, 2013 at 2:20 PM, Pablo <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     >>> Hello,
>     >>>
>     >>>   I have readed this document
>     >>>
>     http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1
>     today [1].
>     >>>
>     >>> I just wanted to say that I think that the use of any binary
>     data (framing,
>     >>> header compression, etc.) in any place of the "header" part of
>     HTTP protocol
>     >>> is not good; so, please only use plaintext for HTTP 2.0
>     because, otherwise,
>     >>> that will make very difficult to "see" the headers's protocol :)
>     >>>
>     >>> Thats all,
>     >>> Thanks for reading this few lines, sorry for my basic English,
>     and I hope
>     >>> that you can re-think all this of using binary data in any
>     part of HTTP X.X
>     >>> (ej: session layer).
>     >>>
>     >>>
>     >>> [1] I started knowing about HTTP 2.0 here:
>     >>>
>     http://webscannotes.com/2012/10/09/http-2-0-officially-in-the-works/
>     >>>
>     >>
>     >
>     > --
>     > Mark Nottingham   http://www.mnot.net/
>     >
>     >
>     >
>     >
>