From nobody Tue Dec 1 07:24:10 2020 Return-Path: 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 762253A1392 for ; Tue, 1 Dec 2020 07:24:08 -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 tIf5g26Gl6ic for ; Tue, 1 Dec 2020 07:24:04 -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 603EA3A1390 for ; Tue, 1 Dec 2020 07:24:01 -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=zvmFRNN2X+k06jgV51ucm4wYdoetw7Nx0TNs/lsZTRM=; b=RZtEw39hnpLtN4exdbYIXgoJuXtqQq4OFxS/WzdVv7SEcNZyKOK8WOgpqBuHxDKZqTt/Ah1CIBr6JaEioi9zlGBc2LGuFA3mMZJW/XmDHMqDyN7yu2VwosGj0Mp5njbtHI95CPPlsfk+dXcgsyGq2wjtSeasDJw4gJ4+yYNW/oztXNUPyK5TdCg/O39UA6vUlbq7q7wKqrP7iAwiz7PTXxOtc5I8wEm+ThYoCPCBEC1+zGS/bFDuiOp021/FE3J3PJPDGCxrt43ssG0BRWx30dQXpBchnWX3mVFR9Jc1b0MHaLjQuqqJbXMOkISaWTJS7gL8jJBTm4ud+6KV1TdHsw==; 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 1kk7VX-0000Zs-0L for ; Tue, 01 Dec 2020 16:23:59 +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 1kk7VU-0007eX-G7 for ; Tue, 01 Dec 2020 16:23:58 +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 ) id 1kk7VU-0004wo-83 for wpack@ietf.org; Tue, 01 Dec 2020 16:23:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Tue, 01 Dec 2020 16:23:56 +0100 From: Daniel Ehrenberg To: wpack@ietf.org Message-ID: <712bcd2a77095b21c99851f4b22151f7@igalia.com> X-Sender: littledan@igalia.com User-Agent: Roundcube Webmail/1.3.3 Archived-At: Subject: [Wpack] Broadening the WPACK WG charter X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2020 15:24:09 -0000 Hi WPACK WG, I'm very excited by the Web Bundle format being developed in this WG, to represent a bundle of HTTP responses. It has the potential to meet a lot of different needs! Some use cases I'm especially interested in are: - Subresource loading (related to what's described in https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md , potentially with subsetting as in https://docs.google.com/document/d/11t4Ix2bvF1_ZCV9HKfafGfWu82zbOD7aUhZ_FyDAgmA/edit# ) - A format to use within JavaScript/Web tooling across a build pipeline, to represent the whole static part of an application - A way to configure web servers to serve a static directory with the appropriate HTTP headers as well as for serving dynamic subsets of bundles I wrote a gist with my rough thoughts pulling together various aspects of Web Bundle applications at https://gist.github.com/littledan/e01801001c277b0be03b1ca54788505e . I've been discussing it with different web platform and tooling stakeholders, and finding broadly shared interest in meeting these goals with a format like Web Bundles. However, I'm not quite sure how to interpret this group's charter. The charter's streaming and random access design goals are definitely important for the use cases I mentioned. However, I don't know if my goals are in alignment with those of this group: subresource loading is explicitly identified as nice-to-have, and build tooling and serving are not identified. It is great to consider concrete use cases to evaluate and refine the design, but fortunately, in this case, it seems like there is little contradiction among the needs of different applications. The architecture of bundle sections is nicely extensible and can be applied to meet different purposes. So I'm not sure if it's necessary to make a hierarchy placing some use cases above others. How would people feel about generalizing the charter to focus less on *why* the WPACK WG wants to define a Web Bundle, and instead broaden to *what* the group is trying to define (a general-purpose, extensible file format for a bundle of HTTP responses which meets certain properties)? This way, we can bring people into the coalition who might have different motivations for representing this information, and develop a more widely adopted standard to solve this common, reoccurring problem. Thanks, Dan From nobody Tue Dec 1 07:47:28 2020 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ) 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 To: wpack@ietf.org Message-ID: X-Sender: littledan@igalia.com User-Agent: Roundcube Webmail/1.3.3 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Mon Dec 7 01:16:43 2020 Return-Path: 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 6F1253A1254 for ; Mon, 7 Dec 2020 01:16:42 -0800 (PST) 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=lowentropy.net header.b=Y427eZWk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RhMQnJJR 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 OoQK-syJBxIM for ; Mon, 7 Dec 2020 01:16:40 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4143A0E9E for ; Mon, 7 Dec 2020 01:16:40 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D88225C0127 for ; Mon, 7 Dec 2020 04:16:39 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Mon, 07 Dec 2020 04:16:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=Yzu/9AWPsysYN1+Mx9aDNgtQVIRto35 O8bioRibwwwc=; b=Y427eZWk5cGGEvBLR2ElHhpD+471W/kTxFwBqf6ZJkQFhNK IHX1cmSIhSIru2Ek5E/9lw+2yUi69Hc0h8kwBbtkcaB+KXrJSy9+CZV95dgbtw7E vYVZNlbU6i4NMsjtdpNbMVek6f/tkYvals4OHD8KG1nIP8o8A5KCh1ksKzYVR5WD uXEQxIDNW7NN1uNYdseSP/UphWq/NdIo2WCQNoEY7dY7wJZWFj9hA4xT5pk2tADZ pQNOTB1CpO+AeNaI0zI/m2Ez3QeOfRKwEPW1g4PWjcSSjVBCu5lrGUzthbbaRmkS eFv81AZHJJPmL6PWToQL/0BP7As6a9jomSebjlw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm1; bh=Yzu/9A WPsysYN1+Mx9aDNgtQVIRto35O8bioRibwwwc=; b=RhMQnJJR554bY3d6LDoK6b KCFYUTPOdS5mg/wZZEFfztCafrThniN4+Y/tZrsa6/aBOmYPpIOCMrj8IuqkfbOe v1qS4YziVJGHOf2bpk4QgFMICRAEun/yFgTqLCsgPmeeQN2S12OqjuvHRJB5KR6E Pnc7Gn4kmdfuCc203rdkMUWSIwRotCZx2Dwl8K+NWBFZRlFzjZC/JX6KAWgq+1Ue jBMEX6N4/EIr2WHAiksa+waAji5p+4mUfNjbJjJDgbbDkY7ErHYRNUWblHdtO0BQ 1q6V+lIYIa83pWHxx69db89voKca6MErex6NNjATS4O6L7dfQdWrpicG0g6SBnVQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejgedgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepgfejkedthefgvdfffeejgfevjeeiueeutdeikeelgfdtieevvdfg hfelgeefkedunecuffhomhgrihhnpehhthhtphhrvghsphhonhhsvghsrdhithdpghhith hhuhgsrdgtohhmpdhgohhoghhlvgdrtghomhdpihgvthhfrdhorhhgnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhroh hphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3D611200C4; Mon, 7 Dec 2020 04:16:39 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <0644699e-182b-4fc0-bcac-047f7bbdddec@www.fastmail.com> In-Reply-To: <712bcd2a77095b21c99851f4b22151f7@igalia.com> References: <712bcd2a77095b21c99851f4b22151f7@igalia.com> Date: Mon, 07 Dec 2020 20:16:19 +1100 From: "Martin Thomson" To: wpack@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] Broadening the WPACK WG charter X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 09:16:43 -0000 The idea that one resource can speak for another resource remains something I'm concerned about. This is a property of several of these proposals and - as far as I can tell - not well motivated by use cases. I realize that you have narrowly scoped the replacement model, but I don't think that is sufficient. Until now, the notion of relative references and paths have only had limited use in the web security model. (I still hold the view that the prefix in SW is a mistake, but that is a weaker notion than the one you propose.) I think that it would be better to have complete encapsulation. That is, resources in a bundle have identity only within the context of that bundle. As for your question about chartered scope, I see no fundamental reason that your design and ideas can't be discussed here in terms of format, resource identification, security, and those things that are already in chartered scope. The details of the specific proposals are a little too wordy for me to distill though. It seems like a lot of what you are trying to tackle is directly part of how browsers work, which is not in scope here. On Wed, Dec 2, 2020, at 02:23, Daniel Ehrenberg wrote: > Hi WPACK WG, > > I'm very excited by the Web Bundle format being developed in this WG, to > represent a bundle of HTTP responses. It has the potential to meet a lot > of different needs! Some use cases I'm especially interested in are: > - Subresource loading (related to what's described in > https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md > , potentially with subsetting as in > https://docs.google.com/document/d/11t4Ix2bvF1_ZCV9HKfafGfWu82zbOD7aUhZ_FyDAgmA/edit# > ) > - A format to use within JavaScript/Web tooling across a build pipeline, > to represent the whole static part of an application > - A way to configure web servers to serve a static directory with the > appropriate HTTP headers as well as for serving dynamic subsets of > bundles > > I wrote a gist with my rough thoughts pulling together various aspects > of Web Bundle applications at > https://gist.github.com/littledan/e01801001c277b0be03b1ca54788505e . > I've been discussing it with different web platform and tooling > stakeholders, and finding broadly shared interest in meeting these goals > with a format like Web Bundles. > > However, I'm not quite sure how to interpret this group's charter. The > charter's streaming and random access design goals are definitely > important for the use cases I mentioned. However, I don't know if my > goals are in alignment with those of this group: subresource loading is > explicitly identified as nice-to-have, and build tooling and serving are > not identified. It is great to consider concrete use cases to evaluate > and refine the design, but fortunately, in this case, it seems like > there is little contradiction among the needs of different applications. > The architecture of bundle sections is nicely extensible and can be > applied to meet different purposes. So I'm not sure if it's necessary to > make a hierarchy placing some use cases above others. > > How would people feel about generalizing the charter to focus less on > *why* the WPACK WG wants to define a Web Bundle, and instead broaden to > *what* the group is trying to define (a general-purpose, extensible file > format for a bundle of HTTP responses which meets certain properties)? > This way, we can bring people into the coalition who might have > different motivations for representing this information, and develop a > more widely adopted standard to solve this common, reoccurring problem. > > Thanks, > Dan > > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack >