draft-kamp-httpbis-structure-00 comments

Martin Thomson <martin.thomson@gmail.com> Mon, 10 October 2016 22:41 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 79F2B1293DA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 10 Oct 2016 15:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.517
X-Spam-Level:
X-Spam-Status: No, score=-9.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PeWsYHCTANy for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 10 Oct 2016 15:41:56 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AD4127071 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 10 Oct 2016 15:41:56 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1btjCh-0005Er-W4 for ietf-http-wg-dist@listhub.w3.org; Mon, 10 Oct 2016 22:37:52 +0000
Resent-Date: Mon, 10 Oct 2016 22:37:51 +0000
Resent-Message-Id: <E1btjCh-0005Er-W4@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <martin.thomson@gmail.com>) id 1btjCc-0005E0-9E for ietf-http-wg@listhub.w3.org; Mon, 10 Oct 2016 22:37:46 +0000
Received: from mail-qt0-f175.google.com ([209.85.216.175]) by lisa.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <martin.thomson@gmail.com>) id 1btjCa-0007ky-Ll for ietf-http-wg@w3.org; Mon, 10 Oct 2016 22:37:45 +0000
Received: by mail-qt0-f175.google.com with SMTP id s49so2054105qta.0 for <ietf-http-wg@w3.org>; Mon, 10 Oct 2016 15:37:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=smJreS+rGhpEO5DR+JXx8r4VIiKndHGOL5BXde49blc=; b=zxixeCfr7rO+Q6PLRePOz5O0/Nq8IcWF9+EodVkR54uys5xN/sWGxDfsy6GZDuZz0z BpvbCZLw91w4hP2z7H9VnfkRuz01SlZ0OeU9s35Svh+6emu1N1q3NpgKqgPVsvvgQ82B buNe2VmyWV+k0i9FEjgtQ5jbRuHFC8QWLbE/SAGji9P/FGHpvg+aaDxra8a5WR6judEL HW3Ak+fQZfFM0OnzQXUYeXKMhx8Uc71QlFdv+jPI+d+Du+zDh8Y6QjGvvKcNjqKYSrer m7KPE2i7nBZHKgYdFH4kdScb4XcrsbTHu+kgGAiQA24YNhUn9oAd6mELjgOQxtIv8Brw xJTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=smJreS+rGhpEO5DR+JXx8r4VIiKndHGOL5BXde49blc=; b=gFhAqeHgiZC2lylUJtow/bpFD8+JhzXsq4pCi7k0X44ftLvbof8DjQev+oq0VMjiSX VuXZ1/9t+IbLJgpZI4mQsn4TASBMJDoc8Ge07vdurNZTL3UW1dUSZKYVy939A2Ff9pBH TgrXulBmrRo9XDQyMrXTnoHdAdQfPD073bSg3vYdmxT1QFnH+cBNq9OI+dVPFDQ4MZEA dHwftWANF7Yu41yyPNzxDU/q+b0dNG7ZD9YC07ZBE41/hJ+0AKeRw6WT5fZYRe1VZiR7 KFHce/jhi/l3Bz8rKywz9D3rvLxatLGp/okj3ZoC8hqHdp3M5uedh+tOxvrCOshAFFYi rrrA==
X-Gm-Message-State: AA6/9RkMNkU6mcgxkFY7OBp+v74xKYo9X2d3IZEB1HO5F4AZhDHx5uSUoAcEsFvPNzwHKmW7EGkT0DL8bZoKHw==
X-Received: by 10.237.59.123 with SMTP id q56mr603738qte.116.1476139038112; Mon, 10 Oct 2016 15:37:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Mon, 10 Oct 2016 15:37:17 -0700 (PDT)
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 11 Oct 2016 09:37:17 +1100
Message-ID: <CABkgnnUD3BXPLKCjSJdWPxwdE89vh4a+UA--19VxMwQXQ64_Rg@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=209.85.216.175; envelope-from=martin.thomson@gmail.com; helo=mail-qt0-f175.google.com
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: AWL=0.082, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1btjCa-0007ky-Ll 545c412c37acf0ad890e3fd8b7df55f1
X-Original-To: ietf-http-wg@w3.org
Subject: draft-kamp-httpbis-structure-00 comments
Archived-At: <http://www.w3.org/mid/CABkgnnUD3BXPLKCjSJdWPxwdE89vh4a+UA--19VxMwQXQ64_Rg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32542
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>

I've spent a bit of time thinking about this, and that there is
probably something here, but I'm not sure what it is.  I'd like to see
if we can up-level the discussion a little and concentrate on what we
have and what we want.

I want to concentrate on these issues rather than the specifics of the
document, because I'm not sure that the document is clear enough about
articulating its goals right now.  The introduction is pretty good
about setting out the state of play (it's a mess), but I would really
appreciate it it it also included both a desired end-state and a plan
for reaching that place.

1. Desired end-state

Though it is not stated, there are many potential properties we might
want to obtain by making this sort of change:
 - more consistent representation of header fields
 - easier to specify new, compatible header fields
 - more capable header fields (more resolution on dates, for instance)
 - more efficient parsing and processing code
 - smaller header field representations
 - (there are probably some other goals too)

The draft is clearly aiming at the some of these, but it's less clear
about its stance with respect to some of the other ones.

Any draft also needs to describe when an implementation might use
whatever tools the draft describes.  It looks like the intent is to
find "compatible" header fields, but to what end?  After all,
virtually all header fields can be made compatible by cramming them
into a string (that's essentially the mess we have today), so there
has to be something better than that.

The draft should at least acknowledge incentive to deploy.  In order
for it to be attractive to both clients and servers to support this,
they need to see some tangible benefits.  I can say that from a
browser perspective, reliability and performance are pretty good
incentives.  Parsing efficiency isn't a big deal for us, and new code
has an automatic reliability penalty, so a more compact form might be
a good place to look.  Clearly, constrained implementations (and
servers count) benefit greatly from parsing efficiencies.

2. Getting from here to there

Presumably the plan is to find some place that a new encoding can be
used and use the encoding there.

But the draft describes how to encode header fields in a new syntax
that is distinctly different to existing header fields, and therefore
definitively incompatible.  That implies the need for some way to
decide to send header fields in this new form.  It mentions existing
header fields, but offers no plan that would let a client or server
decide to use this form.

I can imagine negotiating support for this in HTTP/2 with settings or
something like that (it's surprisingly complicated in practice); I can
also imagine that a server might advertise support for this using a
.well-known resource (YAWK); I can even imagine using connection-level
negotiation in http/1.1 with an inter-request stateful mechanism
(YUCK).

It's never going to be possible to construct a rule to translate an
arbitrary header field unless you want to commit to crappy
translations for stuff that exists now that we don't bother to create
good rules for.  That probably means you will need a way to learn on a
per-header-field basis whether the common form is supported.  That
might be done in sets (you could provide rules for the existing set of
registered header fields), but NeckoFace:>n< probably isn't going to
be something you can use from the outset.