Re: [dispatch] Building Blocks for HTTP APIs - next steps

Mark Nottingham <mnot@mnot.net> Wed, 05 August 2020 04:37 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 831C23A0A9D for <dispatch@ietfa.amsl.com>; Tue, 4 Aug 2020 21:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=Td/dQvOM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=evMYSmKX
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 1rHoAXlEfxtD for <dispatch@ietfa.amsl.com>; Tue, 4 Aug 2020 21:37:03 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B7C3A0128 for <dispatch@ietf.org>; Tue, 4 Aug 2020 21:37:02 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3B9C35C013C; Wed, 5 Aug 2020 00:37:02 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 05 Aug 2020 00:37:02 -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=L rC5RqLp2AuziWRBLmOs1e7D5Rrq1NSsdYhc/wxYhbY=; b=Td/dQvOMYjt+xVaPE P596fpbHvT58kWTQdobDhMfH/m8MbjKUxZ4wdxPD8f1z1+8STnRl0MDTsXP1e5Fn bA1a0Nv+sFfeiApNJYU83u4l2mXviCs6LFgoN+akfuccLW8jS1LokPig7lfCMFu6 oiS43XvG8tNZlJMAe2ojidbzX2kpFHYJ1eDQfBDKKaxnUzIvSqWz84/kBDyTwYl0 +bdKHMCpXacA6qflv7WKOpXOR+JaFaSR7NcpcUe5P0fkNw6+Ebg1KfeaOJRAB2l8 p6ZiyMCeTLuJaOU/0D/3Trqfhyv/nh4n67tFz5RtY1Z0eN8OVY9fZO7e/YAY892h 3RYkw==
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=LrC5RqLp2AuziWRBLmOs1e7D5Rrq1NSsdYhc/wxYh bY=; b=evMYSmKXVTlLIyScPMIEMYdyDYl4FOcN4oaowhsD4FIITU0HYfIXCDDNf RoPyENozwQHojzvyOqkWohzoAy9m1Z7QpidsbXxaeG+uS81xWQ3mRx3tbayo+IC5 dCJh+FluSyvVSux4v2eRN5PvYPtmvfpC1ilSsSWoZ2SCkxOlfDUep7COr3SvYzpZ b9SxEJHjebVAQInGoWwcIczVh4FishANOkykmdq1IXr5Uoo5NBFHLKmgF+NtPsMZ xJBkItvo0h38gdZ4HyeObWnERGfUib/1yGctXVDkI4ee5an1DNv84k9lRxmvIXJP sXdLUHUdRtnEkR4yTEPxHSVpExjxA==
X-ME-Sender: <xms:bDcqX749PJIVux74Qd-S_PF_KD7jYyhz3O0Q9Rf8gbeSu1nw09TJNQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrjeejgdekiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhe dunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhn ohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:bDcqXw4aPVqYc24hU6EKBBfBP_EOXS5waoZ6Go9N1BXKq_9md_-w_Q> <xmx:bDcqXycEtXGURG0tKTRjK0hE3uF-lgATgIPHQyPW4SYkJ-RuvFKC-A> <xmx:bDcqX8I6pfbVU6Cf5odhYgDOHtqm0wgpKeQq1JB2ZAqZSLB-4i5weQ> <xmx:bjcqX1gcLILZZ1qbfPmh-MxI3O9WD9Afkn3AXLr7fLvTCqUQ-MY2Hw>
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 BCC3F328005A; Wed, 5 Aug 2020 00:36:59 -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: <CAD3-0rMfgUhxrAQfCcZrRhUTrSzRE-gDigt0T5qQgQ=nF5O3LQ@mail.gmail.com>
Date: Wed, 05 Aug 2020 14:36:56 +1000
Cc: DISPATCH WG <dispatch@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B33EE11-84E6-4ED0-B1E0-713A4F75FBFD@mnot.net>
References: <FED20ECD-A850-407E-B0DE-59A43B8D318E@mnot.net> <667c26a0-c0a3-96a8-4bd9-18568607ca5f@gmx.de> <CAD3-0rMfgUhxrAQfCcZrRhUTrSzRE-gDigt0T5qQgQ=nF5O3LQ@mail.gmail.com>
To: Wenbo Zhu <wenboz=40google.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/1Ios78MKPtvsldHuYV8OTyS8e4A>
Subject: Re: [dispatch] Building Blocks for HTTP APIs - next steps
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: Wed, 05 Aug 2020 04:37:06 -0000

> On 1 Aug 2020, at 3:46 am, Wenbo Zhu <wenboz=40google.com@dmarc.ietf.org> wrote:
> 
> > HTTP is often for not only Web browsing, but also machine-to-machine communication ....
> 
> Are we talking about "HTTP as a transport" here, which includes e.g. "apis" (external consumption, e.g.. ws), micro-services (rpcs), messaging frameworks, non-browser-clients etc etc ... ?

Yes. The charter frames the work by starting with 'HTTP is often for not only Web browsing, but also machine-to-machine communication'...

> 
> > broad representation from across the industry -- e.g., API gateway vendors (and other intermediaries), API consultants, API tool vendors, in-house API team
> 
> This seems to suggest we are only interested in use cases when HTTP is used as the transport for public API end-points

I think that's a primary interest; this being the IETF, we're interested in the Internet, and if private networks can get benefit / leverage from what we do, that's great, but we shouldn't be constrained by them.

Cheers,


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