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

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" <tbray@textuality.com
> <mailto:tbray@textuality.com>> 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 <mnot@mnot.net
>     <mailto:mnot@mnot.net>> 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 (陈智昌)
>     <willchan@chromium.org <mailto:willchan@chromium.org>> 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 <paa.listas@gmail.com
>     <mailto:paa.listas@gmail.com>> 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/
>     >
>     >
>     >
>     >
>