Re: [dispatch] A WG for HTTP API Building Blocks

Michael Toomim <> Thu, 16 July 2020 09:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 997923A1215 for <>; Thu, 16 Jul 2020 02:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id asHPEKjiBvre for <>; Thu, 16 Jul 2020 02:00:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::641]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BA783A11FE for <>; Thu, 16 Jul 2020 02:00:06 -0700 (PDT)
Received: by with SMTP id w17so3571193ply.11 for <>; Thu, 16 Jul 2020 02:00:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E3sdh1Fy7LsQL1z9GZC0ruUyOw9POEpTkluA4/z3f20=; b=Q72fIZOZR/xDGsQFRQT8+NT7/fJUunGUEtj0Gl02uycnNlOktcAPYnGXfLkCbH3kiM 1JFxTiidTTWCcJrTUl0mOkf4Hl/TgwyqZTN2nS9zMHfCCJL0/pZpgZR2NVcqS4DBOrec XojKkXS+hLnOSWvBPZ1TDZMWLxeltKsEfjXoNVDo/MBeiqGIkSHO5ecojX18dst6An9z QEuwQzcdsEIFMtSXrCfHyMc/MhTS/8MLj6JWYgwseYZg/jUBIws6vY6McU/KHWXgzkBH cZGzWGBvgIfu9tdRKq1b3cMFNnQ81aBmI8UW7rev1FkOunHN6ayyvvJo8DpJvsCrDx61 x2VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E3sdh1Fy7LsQL1z9GZC0ruUyOw9POEpTkluA4/z3f20=; b=Ey9lVxezLngw1xgV6YM1KVqO4jeRgmFxhm0u4RpnRRwQAEawHIuWK5H0AoTB30/Civ IP2lU2tBS+KodniaFlhAuGHihR4XWmJ8hCNVqmLDO3b3hCJQbBIyp9fr/5MQFHcLulh7 kHQPnalE6KDQacglD4XZp23rdzYZkA+qbUXo74os0t/O9eEwhzjczjD5/wT9nsfDj3Mv OaR36LcdHlrj+PHAOkEWWQ9IyAlwDhwL8L2y1GhPH1diYI38/evtIrtivqZyrhnHJrW+ eyYABGHx/iIAm1LixFHhs+E9oXW0kdhESztPARQJwsFv2z4KYEvB4lYm8/3KkLJ75aAQ LiLg==
X-Gm-Message-State: AOAM532nySGTpg8YnmkHR5f91iy9MFcyqsRx2lWPjXBDs2iEC96Lh90q DQkya2015/1R14ciwGPMycA4dnxd
X-Google-Smtp-Source: ABdhPJzjUI2/1SbRmMcju6ObpGME/3jYClPThu8RZn5AOBT9Uo5ix7JkcQspVlwilHhIaUuMGpYeKA==
X-Received: by 2002:a17:90a:368c:: with SMTP id t12mr3816651pjb.90.1594890005677; Thu, 16 Jul 2020 02:00:05 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id r17sm4371451pfg.62.2020. (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 16 Jul 2020 02:00:05 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Michael Toomim <>
In-Reply-To: <>
Date: Thu, 16 Jul 2020 02:00:04 -0700
Cc: Lucas Pardue <>, DISPATCH WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Mark Nottingham <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [dispatch] A WG for HTTP API Building Blocks
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Jul 2020 09:00:08 -0000

Thanks Mark, but my question wasn't about how to get a particular proposal adopted.  I'm trying to find clarity on how we would distinguish these two working groups.

The purpose of these two examples (one current proposal, one historical) is just to give us something concrete to deliberate.  Are these examples of HTTP work, or HTTP API work?

Distinguishing these groups seems important because they are so similar.  If we have trouble identifying which group should take which work right now, when nothing is at stake, I could imagine difficulties at scale.  I'd love to find some clear criteria.

> On Jul 16, 2020, at 1:09 AM, Mark Nottingham <> wrote:
> Great example. 
> I think that if you got HTTP WG folks excited about BRAID and some folks putting their hands up to implement it there, it would take it on. So far, the reaction has been of interest, but I'm not sure we're quite to the point where we'll adopt it; personally I'm still looking for more people to say 'yes, I want to implement that' and/or 'yes, I have a use case for that.' That may still happen, in time.
> If not, and we had an HTTP APIs WG, you could take it there and see if you could get traction with that community; since it's not defining new methods or status codes, and it doesn't necessarily need browser implementation to be useful, that should work.
> There's one proviso, however; if the HTTP WG thought it was a bad idea (e.g., actively harmful, bad for HTTP, conflicting with other work, or just a bad starting point for work) it wouldn't be good for the HTTP APIs WG to take it on, because that would be 'venue shopping.'
> Does that help? 
>> On 16 Jul 2020, at 5:56 pm, Michael Toomim <> wrote:
>> I also see value in recruiting API developers and consumers, but (like Lucas) I struggle to distinguish whether a particular proposal "foo" would be demarcated as HTTP vs. HTTP API.
>> As a present example, how do we classify the Braid proposal?
>> On the one hand, we could describe it as "push-update for REST APIs", and then put it into the HTTP API bucket.
>> But on the other, Braid also applies to browsers and proxies, where it improves caching, reduces network traffic, and allows pages to update automatically without a reload button.  That sounds like core HTTP.
>> Historical examples could also be interesting.  How do we classify HTTP Live Streaming?
>> This is an API standard, which does not need special browser support.  However, most mobile browsers (but not desktop) now have native implementations for better performance.  Does that make it HTTP core?
> --
> Mark Nottingham