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

Mark Nottingham <mnot@mnot.net> Thu, 16 July 2020 08:10 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1253F3A10DC for <dispatch@ietfa.amsl.com>; Thu, 16 Jul 2020 01:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=leyLsY/w; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CvvcDv1P
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 YTgvzP6HazZx for <dispatch@ietfa.amsl.com>; Thu, 16 Jul 2020 01:10:05 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53CEF3A0838 for <dispatch@ietf.org>; Thu, 16 Jul 2020 01:09:44 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 628D55C0170; Thu, 16 Jul 2020 04:09:43 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 16 Jul 2020 04:09:43 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=e Bu6jDFiJy4vwZ3wtYpHzhxC/9VO/klk585r37uYwX4=; b=leyLsY/w6Rj0alkGJ BR8ZRvwg7+OK/U0ZtjgZTtX6fWdl4yHQXshcZkTb6rcza9cbcnXBV+T2ntA5eD9b kBuW8iyqg31Es7jEqQfR7u8tEJBNoj763SfSNS8AU2Vk7rRKLIxTwFh98L0Hezg7 4YYBb7FjM/EelYuvdDbkS+zCBnKLv6Q5QLhC142dSiPSdjUemuy15KClwxEMC98J /zkexFsP2ALYnml3Fc4LiX3BtcoOSafhTIeSM4g+mzADic3GZB4tyGxijotVxNT2 7rVej57ni5Fh3IwSdN01hZ+YguGtdlvqTHB/YaQoFogB/KFciYPDcF51rDxLdNaF /rXBw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=eBu6jDFiJy4vwZ3wtYpHzhxC/9VO/klk585r37uYw X4=; b=CvvcDv1PRUaiji4bi7cO9jLjWxbtELHUL3GFS0MkpLimOJBw9WwlUQI7I JNFbCqPIJ0eg3O8v33XN4OYpdUgIin7FOJHRoNJT9zRdKHtCamBYaKPQzALdNCqi uoFC0WAkmev7mAB+GiOyOQve+QCfouAG1tSNKTC0xxU8FaGCX2GYiGr/pIRC+TPn 0Cam536DTqOUg7II7jpmN089b0JtB2rGnRvjIMUgIhMxXvtV1PMH478xzPT//Psg EX9tQFOJgAI12IGfJRBUziaAXyicc9WOIRcBofLSCcyrtQOdUuabUQnO3L0bO+Lk fAk+49WJu+y07MAUoeNI1k7pw4wsA==
X-ME-Sender: <xms:RgsQX-TLm2Jxldq5nkiGtNil5-Rf-xt0OU_oj36Zfr7R1fR1WHw7fQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfeeggddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepjeeigeekuefhhefgheetvddtlefhvdehhfelvdegleffhedvuddtueeguedukeeg necuffhomhgrihhnpehhthhtphgrphhirdgrshdpihgvthhfrdhorhhgpdhhihhsthhorh hitggrlhgvgigrmhhplhgvshgtohhulhgurghlshhosggvihhnthgvrhgvshhtihhnghdr hhhofidpmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhn ohhtrdhnvght
X-ME-Proxy: <xmx:RgsQXzzEquuLeRJk_oWDhDTVmWYFXRG_iGzGCW-QzQ3a6hTguPt5Qw> <xmx:RgsQX73Ns6p_k3OBRVoaqmqgjd0PaVXQuPsJh8-04xIAPwlLMCRZ2Q> <xmx:RgsQX6DThQ5N3SNnnwcPevq3qHyhAsJZZi0QvfkqeCFoBkcwF3EtBg> <xmx:RwsQX6sjIy9abxdu-XQN09_e63qiaM6o4nP59zkr50VgNIWSUVmaDA>
Received: from marks-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 73A8C3060067; Thu, 16 Jul 2020 04:09:41 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <99642E4F-047C-4A2B-801C-E4E3FA3265E6@gmail.com>
Date: Thu, 16 Jul 2020 18:09:38 +1000
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, DISPATCH WG <dispatch@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E91B85C4-7B37-44BF-8423-65DF63CF33FA@mnot.net>
References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> <CALGR9oaE8XFdEgOmUWhmP_J89_s-+Xr8hyy5iTZ5SXfkX3aa_g@mail.gmail.com> <B4F7AAFD-BF05-4FF1-A960-827F237C02BB@mnot.net> <99642E4F-047C-4A2B-801C-E4E3FA3265E6@gmail.com>
To: Michael Toomim <toomim@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/09SK6tGIzmTFHN7WqaEcQChLAbM>
Subject: Re: [dispatch] A WG for HTTP API Building Blocks
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2020 08:10:09 -0000

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 <toomim@gmail.com> 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?
> 
>    https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http
> 
> 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?
> 
>    https://tools.ietf.org/html/rfc8216
> 
> 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   https://www.mnot.net/