IETF Logo Mail Archive

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

Mark Nottingham <mnot@mnot.net> Wed, 15 July 2020 06:14 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 62E163A093B for <dispatch@ietfa.amsl.com>; Tue, 14 Jul 2020 23:14:59 -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=k2th/jtE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XBbzIrGq
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 LXUbtxvQZgiN for <dispatch@ietfa.amsl.com>; Tue, 14 Jul 2020 23:14:57 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8823A3A0936 for <dispatch@ietf.org>; Tue, 14 Jul 2020 23:14:57 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 921F5AD8; Wed, 15 Jul 2020 02:14:56 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 15 Jul 2020 02:14:56 -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=F rgdJCGB9djDXraUqY5D9n0nHI5BXcBHpNOFHrgIehs=; b=k2th/jtEbiHFZyrKY 8UkQ7EOj8nwX1LP3Elg35omWAN4Sfcei81KomI0wRlml8lHi4JLDDbTHltMMiAP4 YwlVPxTBiNYaSZZ6at/ip/X/oUjaB5+lV1/JDq1UiUBBf3ehvdLpFsi+bU1/i5oT mDcESnYeCWqdXcUIj8GH42zkvfmwYwcs3jwCkgnCDE1wZTL1PCa98IZ+hfzmTjNY P2BgYWzpeagn9tgXd2+Id7PONjxbuIGrdzhz6P9EP3XnIgDONUtUr+xM6VbIZ4GV KNb950C7KMJaTHTze/hdcaG4ioyEAmXDTomX8KUaX7puZ8dRAOZe1aXLyg+Vbl9P oyUxQ==
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=FrgdJCGB9djDXraUqY5D9n0nHI5BXcBHpNOFHrgIe hs=; b=XBbzIrGqvtqjWJet1x8IOhRZON+SYZrwgoEw3RU+tFS9nkNE907POvr3P HmrfUiysAtFhUZ7bsy/C6Yd1xTRNMxdcbxAURg8XY8y22DjwLHuXEwpz2zam1b/g qqZH1nmwUPM8w4ZGU8HdZvWnNpDYL5VFnEh9645z1geXijBPGUsP/6OBbwRXV0TY zBwCggukhB7GvQfADNveYdAYOpX+xT35LMYFgIKO4CUsscFFtrYVfc0XGNGdQxwv z/RbeCfpPbrM7Y4XFx1WDdn29bFtzX9vagWmgv2F1h2SPzbmhIafnl4jLM3K8znx eUx20MJa3bGGQn1TUkiOIyMyouLdQ==
X-ME-Sender: <xms:354OX7JsIhTbMANJXat83lMkHsq2dLzSyBS8GWvWX9QA7jnF17h-hA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedugddutdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeevffffhfduteevvefhueffieegtdeutdehffeltefffedttdeggeejheeiueet teenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:354OX_JPXli3MTYrI2LHj0dbXFhsOa1DO0bgJu9ztSnFiWJPEXBtsg> <xmx:354OXzvOc-KprcvXEND-0dhcfgAqsQdkaiXQne9cxT4e0mjFyLFBWQ> <xmx:354OX0Y93wPzy7SyuNwf4qrG-zTrIxdKaQf17ZAmkvXKZeENikWKlQ> <xmx:4J4OX1xrSpdJ-BF0a3Vm56rK1fi7h2ZBBZvq-td_XtQvV1VrSyAF5w>
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 6269E3280059; Wed, 15 Jul 2020 02:14:54 -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: <CALGR9oaE8XFdEgOmUWhmP_J89_s-+Xr8hyy5iTZ5SXfkX3aa_g@mail.gmail.com>
Date: Wed, 15 Jul 2020 16:14:51 +1000
Cc: DISPATCH WG <dispatch@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B4F7AAFD-BF05-4FF1-A960-827F237C02BB@mnot.net>
References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> <CALGR9oaE8XFdEgOmUWhmP_J89_s-+Xr8hyy5iTZ5SXfkX3aa_g@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/Dy803UIL9zAdBaDkRmubm1xKn8U>
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: Wed, 15 Jul 2020 06:14:59 -0000

Hi Lucas,

> On 15 Jul 2020, at 9:36 am, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:
> 
> On a personal note, I struggle a bit to understand how some proposal "foo" would be demarcated as HTTP vs HTTP API. That is probably case in point for the need of a community that understands these things better than me. 

There's definitely a grey area, and I suspect it will take communication and negotiation -- which is often the case between WGs anyway (we've had several of these kinds of interactions between HTTP and other groups like QUIC, DISPATCH and SECDISPATCH).

> I suspect my problem is that the interpretation of browsing is a little open and the charter could benefit from being arbitrarily more explicit. For instance, one pattern that is emerging is building Internet applications around the Web Platform but otherwise not supporting the notion of "general purpose web browsing", examples I have in mind are Progressive Web Apps, applications built on top of Electron, or "TV apps" in media clients. Therefore, the statement "[will not define] new extensions that are likely to be used by Web browsers" seems to rule out technologies and that seems a bit unfair.

One differentiating factor is whether the new protocol element is likely to be supported in the Web Platform itself (i.e., actually by the browser), or by code that's running in the browser on behalf of the origin. Would that help, if stated as general guidance (I don't think it should be an inflexible rule)?

Cheers,

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

v2.23.0 | Report a Bug | By Email