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

Mark Nottingham <mnot@mnot.net> Tue, 14 July 2020 23:25 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 2CDA53A078E for <dispatch@ietfa.amsl.com>; Tue, 14 Jul 2020 16:25:51 -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=Bh6bOUKs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YE8JK8an
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 qTnDuzXrmjNb for <dispatch@ietfa.amsl.com>; Tue, 14 Jul 2020 16:25:49 -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 505913A0C20 for <dispatch@ietf.org>; Tue, 14 Jul 2020 16:25:15 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id AAEBD5C0113; Tue, 14 Jul 2020 19:25:14 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 14 Jul 2020 19:25:14 -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=k zZRygR2/qF1zqJy3JSrwVFyclCQEG/TgEjjjXRs7n0=; b=Bh6bOUKsFrTScC7n8 F5rMBE13ZbqtXs+fGUxsnEyZYaXWIlJbONVg3QDnQPEMzy0Gq/jrN1hjFPxvAPzs leb6nzmn1vd2VhxvYKuUh78QicRn+u8zjMLGrrWDwROiAnnpL7ND1XHP+qYb59LF M9uNAe+fKPzE8TfYGQJA604k7SmCFGD2171hm88WT1avEHrk5wj/PvgifJVBnhLS FgqBDdm76eIREh1WgFKisjVcRQLZMvb7KZLRgRy8w2YMnv4HTONTy9JJEaXJsN/l AAEibZ6E7231eFr+cPnMwt3rsB/G0DWfWqE6b3M6P7g80oXQW2MiMyyvCRRYewhq 4pz4g==
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=kzZRygR2/qF1zqJy3JSrwVFyclCQEG/TgEjjjXRs7 n0=; b=YE8JK8anT383tZGmiIV5wpgLq/WaMUNPFjXPJCjukdH1Na21lBxB0yPZE LJVuFscVDkK6CdJ4hVWHY/OCwBzXQ2/1uN6I2OtycCAA2xoeDn3UZRjX/70lPvlJ a/5ydxw3riHGzDXq7pMklOpWKjdSOfcdiM0GoMipz7WWhEhmhC87YW9C8xSYIuo5 hjDg7umzHXnpBmrRqL4mraBbZ+hF4cpNM6l3BtJKP9C59YltR6YJArVUUof4WCSq q+H++b2LNP6ALiOtcmHhcl4yuVRGKM9PV4WtnI7CqxnvmzpIvqymea9GoNuC63rj uyl+L7i7UoZHN7LXuplh4vqbQWZ4Q==
X-ME-Sender: <xms:2T4OX6Zcoz8lr3fhX7GrJPxItu5b36vEBwKcvSDhgEIR2Ov0kpruoA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedugddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkedvleehveeiudeihffhfefhvddtgeelhfevfefgjeduudevvdfftdfgudeufefh necuffhomhgrihhnpehhthhtphhinhhouhhrfihorhhkrdhithdpmhhnohhtrdhnvghtne cukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:2T4OX9ayyYLCJQJ01g3M-4BKaHoUxBRtwKULJCFTomOCIN5_l7HRMg> <xmx:2T4OX0_BNU842N6RMZlWhpxDbsTcuG3tSsZUhizcv3RgCNCqGit7YQ> <xmx:2T4OX8q0RwGJuAfBs4bw3HZNb4wFjr4lP5gOzZOk7bOfbbG6uTYtHA> <xmx:2j4OX814o70WvqUOJw7Bl8jlOa_W3btG7SVstqci9oRdLrpUclAWlQ>
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 54A80328005E; Tue, 14 Jul 2020 19:25:12 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <7414026C-4726-4C8E-8C9C-60A81F5456B5@brianrosen.net>
Date: Wed, 15 Jul 2020 09:25:08 +1000
Cc: Mary Barnes <mary.ietf.barnes@gmail.com>, DISPATCH WG <dispatch@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <506832AD-0C3C-43AA-B5A7-EB5E80A2A112@mnot.net>
References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> <CAHBDyN7BGsBJ4=+boBAAP5Z+ZT+pFfQ-iJtSa7qHNTP_bGyXeQ@mail.gmail.com> <7414026C-4726-4C8E-8C9C-60A81F5456B5@brianrosen.net>
To: Brian Rosen <br@brianrosen.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/62NEHKRo5gfyzm1EJHfmqqoqSm8>
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: Tue, 14 Jul 2020 23:25:51 -0000

Hi Brian,

> On 15 Jul 2020, at 5:59 am, Brian Rosen <br@brianrosen.net> wrote:
> 
> One question about the charter:  We’re going to see an increasing incidence of defining protocols using json and HTTP in our work.  It would be good if the IETF had some common way these interfaces were defined: not just the schemas but the operations.  This is the domain of OpenAPI, for example, which could be a candidate for what I’m asking about.  Is that something that would be a chartered item?  I’d be willing to work on that.  Not proscriptive, just advisory — there are going to be plenty of interfaces that wouldn’t fit, but things that use an HTTP verb, take some parameters in, possibly including json objects, and return some json response could benefit from some common defined way to describe them.

My .02 - I think it might be eventually, but I'd like to see the WG build some capacity and legitimacy first. I say that because there are some issues (like interface description) that have multiple possible solutions, and I don't think we should be in the business of 'picking winners' unless we are able to demonstrate that we have engagement broadly across the industry. Hence the focus on 'building blocks' rather than complete solutions.

Cheers,

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