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

Mark Nottingham <mnot@mnot.net> Thu, 16 July 2020 09:12 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 16D9D3A123C for <dispatch@ietfa.amsl.com>; Thu, 16 Jul 2020 02:12:16 -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=lXxFL4jF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sW4mWbRf
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 OXY9Rcjk09Es for <dispatch@ietfa.amsl.com>; Thu, 16 Jul 2020 02:12:14 -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 52FFE3A1238 for <dispatch@ietf.org>; Thu, 16 Jul 2020 02:12:14 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7B6425C0113; Thu, 16 Jul 2020 05:12:13 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 16 Jul 2020 05:12:13 -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=U 8rYPf2TSPH2Uic1H5jC7WPA90oCt6sxW5rQUuy16ds=; b=lXxFL4jF6vXv9RKAV ZdQBPpAblesxmUP84XnSRSQh5CVUodoBEj0H7YHJMP/Ezq5dDr3HLLDlnLDdlBmq +f7EuL6O7n9MmRHIeEj7TDMpYcCSDV+IiCWwA6HtPiwaytc8EH81b3+d73lJsbSp xErRB8byS9lQm7FM7YPDmgKDNLknOwMTK0bCgoHlnwjNinzOuftPddQ9DKmUm94e GqzVvT6KPRdpfQVjtcU+Q4TIPfUEV8H2rB1z9mVYMtgUySoqFLBaDyvoOUIhWztM ZqPbTD2/uiXoQ0kwt9fTkq4B1e7doK/Yn4Z2GBjiu3U4p3ZhgumCB8TmermR9Z1L ly7pg==
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=U8rYPf2TSPH2Uic1H5jC7WPA90oCt6sxW5rQUuy16 ds=; b=sW4mWbRfAAl6a6z7gbNR8g1kgJe5ErD5tBBjSw2SPq2xBhzek6Hxl+sKH Q5J4wcOkmvagJ+gPuLMd0I/r9RXxtMX7utw/9bvu8pjDBfN0/lF5Mu7bH0WcTd6h 18SBunUdBw4lovO3wwJOFzF3xdNNYuj3h7i55RWgXcDKGvq7APuuDcQUf5jmCntG HKR9ld4Qko9hbJlMt6aNh8VXFcammgmKCwMuvoCyH0acsIbl/QK+0rLwkTe8HTzY mDYqUJU4e+YUo545+k4QHiroU27Iexpk2ZDNC1bq/gtzoZxP3gYkbvIRc7FDKem7 F1mK0KBYc34QupgUhzogKuImlPsWg==
X-ME-Sender: <xms:7BkQX0fZaH28xkz8vfK84SWSgg4CnUFKStGHGccGc_FiYL2yoySiRw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfeeggddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepjeeigeekuefhhefgheetvddtlefhvdehhfelvdegleffhedvuddtueeguedukeeg necuffhomhgrihhnpehhthhtphgrphhirdgrshdpihgvthhfrdhorhhgpdhhihhsthhorh hitggrlhgvgigrmhhplhgvshgtohhulhgurghlshhosggvihhnthgvrhgvshhtihhnghdr hhhofidpmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhn ohhtrdhnvght
X-ME-Proxy: <xmx:7BkQX2NpRMCc7GG0RpUP38aJzIISRzKVwQIJwiD8O42N7JLLHrKm-w> <xmx:7BkQX1gpdEyVXDtNErl7VNJWEBdcM5SeVOw8Z9X8LvT4GDqhDPfeEw> <xmx:7BkQX58WnpxHkK72_aZU6fGpLUNcuVyQqVZ11P8D9PZlwmFzKqjDrQ> <xmx:7RkQX54j64CzBzzDm4C7vtoL5933C1MBdMeoP3dxJewSCH82tSuI8w>
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 8957030600B4; Thu, 16 Jul 2020 05:12:11 -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: <79387279-56D6-495A-9C64-D2AD13F8D47C@gmail.com>
Date: Thu, 16 Jul 2020 19:12:07 +1000
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, DISPATCH WG <dispatch@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DB785972-9BC3-4B53-AACC-C422116D4FA2@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> <E91B85C4-7B37-44BF-8423-65DF63CF33FA@mnot.net> <79387279-56D6-495A-9C64-D2AD13F8D47C@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/-d12une-8jrqztf6_fG_JrMczJw>
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 09:12:16 -0000

It's not necessary to have a mechanical process for determining what group something best belongs in; it's negotiated between the various stakeholders, following any guidance in the RFCs and charters as appropriate. As I mentioned to Lucas, we already encounter this sort of situation in other places (e.g., deciding whether a particular HTTP/3 extension belongs in the QUIC WG, the HTTP WG, or another WG dedicated to that extension's use case).

Cheers,


> On 16 Jul 2020, at 7:00 pm, Michael Toomim <toomim@gmail.com> wrote:
> 
> 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 <mnot@mnot.net> 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 <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/
>> 
> 

--
Mark Nottingham   https://www.mnot.net/