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

Nico Williams <nico@cryptonector.com> Mon, 21 January 2013 00:03 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E15321F8689 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 20 Jan 2013 16:03:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.078
X-Spam-Level:
X-Spam-Status: No, score=-7.078 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqmZRh23WofB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 20 Jan 2013 16:03:16 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id BE09721F8629 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 20 Jan 2013 16:03:16 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Tx4q4-0002uF-F1 for ietf-http-wg-dist@listhub.w3.org; Mon, 21 Jan 2013 00:02:12 +0000
Resent-Date: Mon, 21 Jan 2013 00:02:12 +0000
Resent-Message-Id: <E1Tx4q4-0002uF-F1@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <nico@cryptonector.com>) id 1Tx4q0-0002ta-6n for ietf-http-wg@listhub.w3.org; Mon, 21 Jan 2013 00:02:08 +0000
Received: from caiajhbdcagg.dreamhost.com ([208.97.132.66] helo=homiemail-a88.g.dreamhost.com) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <nico@cryptonector.com>) id 1Tx4pw-0001Cs-9z for ietf-http-wg@w3.org; Mon, 21 Jan 2013 00:02:08 +0000
Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id EFA0D264058 for <ietf-http-wg@w3.org>; Sun, 20 Jan 2013 16:01:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=3q3V7cwp3Ht3z1DueJSGOc5IJFU=; b=H/ws5pIqtnc yxA14YbrwsonZh5kLeCCKUioqzbq/QyTPr7SuoNI6oqtn2gHvZSoNE1ixig2KSVE U/eAPqng2fRzpH7WfPeoiM7I8cnZwc5Cbt2u7lktZU+ZUdz5nTmeUPC5QochOA2N wWGfHuw5TgE8VOwxXVpPd+BHD8uc9+fw=
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 9A95F264057 for <ietf-http-wg@w3.org>; Sun, 20 Jan 2013 16:01:42 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id dq12so3459158wgb.12 for <ietf-http-wg@w3.org>; Sun, 20 Jan 2013 16:01:41 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.77.13 with SMTP id o13mr23373350wjw.58.1358726501235; Sun, 20 Jan 2013 16:01:41 -0800 (PST)
Received: by 10.217.82.73 with HTTP; Sun, 20 Jan 2013 16:01:41 -0800 (PST)
In-Reply-To: <CAA4WUYjyX2QkrfB5Sj8_vyyQuC6Ftx7XsvF+om66D6=EU5V5Qg@mail.gmail.com>
References: <CAAZO4q4vEiYhH5FaX2XCxXox9jkf4dLTy8coQZiE+CYHA-QzBg@mail.gmail.com> <CAA4WUYhkVBRAyY1O32aOiWB8=46SBidFOjKH+e7PGbB7mKzmiQ@mail.gmail.com> <DC03C924-9DCC-45CE-B9DB-5906EADAF9C4@mnot.net> <CAHBU6iuaeAeTrz6TSOyhNvW2pXWgQB_RQ+6MYAb9DyJUZ00Rcg@mail.gmail.com> <CABP7Rbdft=ukmL+vgyJtSTRSVytxMFkX6ctqhqhJ2Njw_OLr1g@mail.gmail.com> <CAA4WUYjyX2QkrfB5Sj8_vyyQuC6Ftx7XsvF+om66D6=EU5V5Qg@mail.gmail.com>
Date: Sun, 20 Jan 2013 18:01:41 -0600
Message-ID: <CAK3OfOiXsjKeuwmX+1JuNL7u8fceQxY0nczjy=6HiBWpgVqYxA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "William Chan (陈智昌)" <willchan@chromium.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: none client-ip=208.97.132.66; envelope-from=nico@cryptonector.com; helo=homiemail-a88.g.dreamhost.com
X-W3C-Hub-Spam-Status: No, score=-4.5
X-W3C-Hub-Spam-Report: AWL=-2.500, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: lisa.w3.org 1Tx4pw-0001Cs-9z 9d5ce3ae278277c8eb9e101013972122
X-Original-To: ietf-http-wg@w3.org
Subject: Re: The use of binary data in any part of HTTP 2.0 is not good
Archived-At: <http://www.w3.org/mid/CAK3OfOiXsjKeuwmX+1JuNL7u8fceQxY0nczjy=6HiBWpgVqYxA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16063
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Sun, Jan 20, 2013 at 5:48 PM, William Chan (陈智昌)
<willchan@chromium.org> wrote:
> [...] Yes, maybe some humans will internalize a binary encoding of
> headers and be able to grok hexdumps, but to the vast majority of
> people, it's basically the same.

Nah, we have plenty of packet capture parsers (Netmon, Wireshark,
tcpdump, snoop, ...).  Wireshark, in particular, is very easy to write
new plugins for, and it's portable.

I'm with Roberto too: it's not really true that textual protocols are
easier to debug, at least not now that we have extensible packet
capture inspection tools.  Further, textual protocols may inhibit the
creation of dissectors for them ("it's text already, what you do need
a dissector for?"), which makes them harder to inspect than binary
protocols.

We can probably apply a lot of minimal encodings of header values (and
header names) in a textual way, but the result would be nearly as
incomprehensible (without tools) to a human as a hex dump of a binary
protocol.  So merely trying to do as best as we can while retaining a
textual nature seems likely to lead to either few gains or a protocol
that's as [in]scrutable as a binary version.

Finally, as others have pointed out, human-readable textual protocols
are likely to allow lots of variations that complicate parsers, thus
being a cause of bugs.

Nico
--