[Wpack] Factoring out some parts of the Web Bundle format

Daniel Ehrenberg <littledan@igalia.com> Tue, 01 December 2020 15:47 UTC

Return-Path: <littledan@igalia.com>
X-Original-To: wpack@ietfa.amsl.com
Delivered-To: wpack@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DDE3A13F0 for <wpack@ietfa.amsl.com>; Tue, 1 Dec 2020 07:47:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=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=igalia.com
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 1rUpuSItJ4YG for <wpack@ietfa.amsl.com>; Tue, 1 Dec 2020 07:47:15 -0800 (PST)
Received: from fanzine.igalia.com (fanzine.igalia.com [178.60.130.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C89B3A13C2 for <wpack@ietf.org>; Tue, 1 Dec 2020 07:47:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=uquSxZ04jQYPIMoCeANID+KUlWO8THOCrytt85z/lnE=; b=I2CTYA2KM4qSrYIXJx2zhSouvI5MCTv9oUVqPru44pUZmw8zuvc8iy/+O5kzHR017YwMBLCbX44r1tijQR4I7Kk4zxmB93GoXap1L3uPkRYCRu6asL6rVxqa4hcIb9hdHxr9FkbdpZFFBtG8uyzYqdAcJApvm1wcqSgxk0mgTf5QXlNFL65Ewks9KBADW6fcg6YhNb5kyudp2uydjT9k70qH3bjS3SVwjQPV+jGxT348tnT5qTRfYZlbWvuNiuGe932z1lf6EF9bYayGfMBnxzNNdOrn4ucchaPx5Wfbpr4KedZM2dczWCnuzw81g/p/ENV5rQU2aimfXx3Fdhtitw==;
Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com) by fanzine.igalia.com with esmtps (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1kk7rx-0002Z1-Sd for <wpack@ietf.org>; Tue, 01 Dec 2020 16:47:09 +0100
Received: from webmail.local.igalia.com ([192.168.10.121]) by mail.igalia.com with esmtps (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1kk7rv-0000ay-FH for <wpack@ietf.org>; Tue, 01 Dec 2020 16:47:09 +0100
Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.local.igalia.com with esmtp (Exim 4.84_2) (envelope-from <littledan@igalia.com>) id 1kk7rv-00051b-73 for wpack@ietf.org; Tue, 01 Dec 2020 16:47:07 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Tue, 01 Dec 2020 16:47:07 +0100
From: Daniel Ehrenberg <littledan@igalia.com>
To: wpack@ietf.org
Message-ID: <e982e945eeed810a26aa7ec376126fa9@igalia.com>
X-Sender: littledan@igalia.com
User-Agent: Roundcube Webmail/1.3.3
Archived-At: <https://mailarchive.ietf.org/arch/msg/wpack/RpDWLC1GZjhGl9ZzcB3kxdIx_w0>
Subject: [Wpack] Factoring out some parts of the Web Bundle format
X-BeenThere: wpack@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Web Packaging <wpack.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wpack>, <mailto:wpack-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wpack/>
List-Post: <mailto:wpack@ietf.org>
List-Help: <mailto:wpack-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wpack>, <mailto:wpack-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2020 15:47:26 -0000

Hi WPACK WG,

As I mentioned in the message "Broadening the WPACK WG charter", I'm
very interested in Web Bundles for subresource loading, e.g.,
https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md
. The Web Bundle format has a great architecture, in terms of having an
extensible set of sections, to permit various different usage profiles.
This WG could use take advantage of this architecture in order to define
a cleanly layered format. In particular, a few features are not used for
subresource loading:
- primary URL: not meaningful, as the bundle is not being navigated to
- manifest section: not used, similarly--the manifest should be linked
from the document which includes the subresources
- variants: not recommended, as content negotiation should be done when
deciding which bundle to include, to avoid wasteful downloads

I think we can factor each of these features out from the core Web
Bundles Internet-Draft and put them into a separate Internet-Draft which
indicates how to use bundles to represent whole pages, much like the
"signatures" section was recently removed from the Web Bundles draft.
For this, I would suggest:
- The primary URL should be located in a separate, optional section,
like the manifest section.
- The primary URL and manifest sections should be factored out into this
other draft
- For variants, the story is a bit trickier, since it is integrated into
the responses section. Honestly, I'm having trouble understanding the
motivation for Web Bundle's variants support, e.g., what use cases it is
meant to satisfy. Some kinds of negotiation (e.g., with Client Hints or
UA) extends outside of the variants model, if I understand correctly. Is
there something else we can do to future-proof the binary format for
this support, rather than including this particular format in the core
RFC?

There are other additional sections which may be useful for some
applications. For example, within build tooling, a section could be
added to represent the dependency graph among subresources. So, Web
Bundles with this modified factoring would represent an excellent basis
for a variety of uses. 

What do you think?

Thanks,
Dan