Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

Andy Green <> Thu, 03 November 2016 10:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD4211298C6 for <>; Thu, 3 Nov 2016 03:36:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.288
X-Spam-Status: No, score=-8.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cicxhd4UD8Ye for <>; Thu, 3 Nov 2016 03:36:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2AC1E1294FC for <>; Thu, 3 Nov 2016 03:36:13 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c2FK9-00030V-HJ for; Thu, 03 Nov 2016 10:32:45 +0000
Resent-Date: Thu, 03 Nov 2016 10:32:45 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c2FK0-0002yP-VT for; Thu, 03 Nov 2016 10:32:37 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1c2FJu-0000mD-Ke for; Thu, 03 Nov 2016 10:32:31 +0000
DKIM-Filter: OpenDKIM Filter v2.10.3 80281D8BD6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1478169113; bh=NooovaRUgIC1dU3vcjP6qi28nQcE5+JTvMXAwfc18X0=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=5JRj/ZjU/YJYP0INXD5TKdIsHek9QUevfdDdFKuEpCFlBA3Diff8N+P5+/1qKdC0v APPYldWuxhvZ1F58Hoft2s4PJvLFj/e50zuY+PcEIhoaoZVNQFECJTdQOP8YD3k5dI UiW8wC0yoUayGFXt7O7tiNfQnFHFH9gd2u0rM3Zw=
Message-ID: <>
From: Andy Green <>
To: Cory Benfield <>, "Roy T. Fielding" <>
Cc: Julian Reschke <>, Kazuho Oku <>, HTTP Working Group <>
Date: Thu, 03 Nov 2016 18:31:52 +0800
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.7
X-W3C-Hub-Spam-Report: AWL=-0.346, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.305, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1c2FJu-0000mD-Ke 7fec8232656f6817f03f5bd40c60bb4b
Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32834
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, 2016-11-03 at 09:08 +0000, Cory Benfield wrote:
> > 
> > On 2 Nov 2016, at 22:50, Roy T. Fielding <> wrote:
> > 
> Sure. But my comment was about having *well-oiled* extension
> mechanisms. Put another way, if you have exactly one place to put an
> extension, then that is where all extensions will be put. This will 

Just jumping in with my tiny bit of experience on this narrow subject
of handwaving standardized extensions.

>From the point of view of ws, extensions were an almost complete
failure and came into being to stop the endless dithering (let us
recall, there were like 80 versions of that standard...) at least in
part caused by Google trying to mutate it into spdy.  It only got out
the door by the sleight of hand of pushing compression and mux into
"extensions" to be discussed later.  Ws mux was stillborn, because
Google passed on the honour and it instead became http/2.

So one of the two major targets for "ws extensions" said "nope", and
the only ws extension in any kind of actual use AFAIK is RFC7692
permessage-deflate.  Doing even that properly (ie, streaming the
deflate in chunks, rather than allocating for inflate of the whole
message) has radical impacts on the whole architecture, and supporting
generic extensions even more so --->

> greatly increase the speed which with the bug-finding use-case will

...therefore many ws implementations support neither extensions in
general nor permessage-deflate specifically.  (You might say, "that's
OK because they are extensions", but they architecturally decided they
repudiated the whole idea of extensions).  So no, it didn't increase
any bug finding.

>From this experience, I think maybe the standards should avoid looking
towards Founding An Empire That Lasts A Thousands Years and just have
it do what it should do.  If you look at http, his "extensions" were
very natural compared to ws reserved bits that will never come into
use, unused extensions bar one, you could just get additional random
headers with a well-defined way to skip what you didn't understand at
the per-header level.  The paleo-headers were "extensible", they were
not "extensions".  Or .well-known, as another example of a positive
pattern,  that didn't extend http at all but is open-ended for what it

I want to suggest "extensions" are a sign the definition of the
protocol has failed...