From nobody Fri Feb 12 16:36:35 2021 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D41D93A11EB; Fri, 12 Feb 2021 16:33:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: superuser@gmail.com, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317640785.31337.14107075493643014792@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:27 -0800 Archived-At: Subject: [Wpack] wpack - Requested session has been scheduled for IETF 110 X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 00:33:36 -0000 Dear Liz Flynn, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. wpack Session 1 (1:00 requested) Friday, 12 March 2021, Session II 1530-1630 Room Name: Room 3 size: 503 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/wpack.ics Request Information: --------------------------------------------------------- Working Group Name: Web Packaging Area Name: Applications and Real-Time Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: quic mls tls dprive dnsop add wish Technology Overlap: httpbis dispatch secdispatch saag acme People who must be present: David C. Lawrence Murray Kucherawy Sean Turner Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Feb 19 11:54:37 2021 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 ECC5E3A143C for ; Fri, 19 Feb 2021 11:54:35 -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 JkEpC49jAMK8 for ; Fri, 19 Feb 2021 11:54:29 -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 9B53A3A1443 for ; Fri, 19 Feb 2021 11:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:In-Reply-To:Subject:To:From:Date:MIME-Version; bh=TOq3S9Pn+/ELxV3Wi5Qe0ZqdlVvyYCIoHsIpAHKfuSg=; b=gIi3H0jGuBK0p50ISXIQ762phbatFBiEfbMdnkTFpzBotP1aJ6na5vcRsrCiUEYls7+qiDz8jrwE4f7SP3Qd6KYW2xq+BFjt2CvZKi8A2MUcPb37r1vjjMY6fQU1G89n0s0S+QB/118R9A4raQp6Pq9O0Hr0w5zCR0wp/uPe9w0otp3i6HV9/8vKaE3vDtCIlj3vN2D1V5EOUZAMAIsIvBKV0xeEAIC/yOt5NmAyKP88SNVVSRkmgJQIoQPJgY5NN9EhKddriYoCEYULqbem4QK5PQlXU5lyiKmcSulGfMIXkGequZtCV7mq/PZKm6aml89lDE35ntHyT5fS9hzFSA==; 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 1lDBr5-0003El-U5 for ; Fri, 19 Feb 2021 20:54:23 +0100 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtps (Cipher TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim) id 1lDBr3-0007EH-DL for ; Fri, 19 Feb 2021 20:54:23 +0100 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.94) (envelope-from ) id 1lDBqx-0000oG-V4 for wpack@ietf.org; Fri, 19 Feb 2021 20:54:16 +0100 MIME-Version: 1.0 Date: Fri, 19 Feb 2021 19:54:15 +0000 From: Daniel Ehrenberg To: wpack@ietf.org In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.11 Message-ID: X-Sender: littledan@igalia.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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: Fri, 19 Feb 2021 19:54:36 -0000 On 2020-12-01 15:47, Daniel Ehrenberg wrote: > 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 I've filed a few PRs against Jeffrey's draft proposal to make these changes [1][2][3]. What do you think? Should we follow up on this topic in the upcoming IETF 110 WPACK WG meeting? Dan [1] https://github.com/WICG/webpackage/pull/617 [2] https://github.com/WICG/webpackage/pull/618 [3] https://github.com/WICG/webpackage/pull/619 From nobody Fri Feb 19 12:26:46 2021 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 5707F3A14C8 for ; Fri, 19 Feb 2021 12:26:45 -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 V7UQJYPTCyZ0 for ; Fri, 19 Feb 2021 12:26:40 -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 6F0683A14CA for ; Fri, 19 Feb 2021 12:26:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:MIME-Version; bh=Qk8WlIGCAMcUIGHNuPAhmV/PM9mFH1TmzO6FPdehdyo=; b=pcenMMouITQ8waIDrVsKJgHwN2E2Afar+ERS110YoKYw0PJr68LrOoLzWOTUYGrK+2TyhXPkAPvvMt5zvDuY3gJwjg/sL5NL7kpzqd0Ozqdwce6oMMb9Hj9lWp2+d5nK1MrOeK1BskvLK1Ey97rLTuCiHvZk14oQtqVhT+wC+TaAsuS/MtGRUh3ElPimvT6xICdqtQGvsNuZlYre0QMslQPIMpSpGUeCeyWXiEzokjDFPC80kNQodzQSlYxeHEtaGu+eQU3q/NkZiRbvmJZGUTN5QRDvG/UVyT17dLRunb6gnu17AeQc06rJkyduRGRm0n8aoWyagaX2R9/j8+7YYg==; 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 1lDCMG-0000xv-O9; Fri, 19 Feb 2021 21:26:36 +0100 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtps (Cipher TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim) id 1lDCME-0000v8-28; Fri, 19 Feb 2021 21:26:36 +0100 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.94) (envelope-from ) id 1lDCM8-0001KD-Jx; Fri, 19 Feb 2021 21:26:28 +0100 MIME-Version: 1.0 Date: Fri, 19 Feb 2021 20:26:28 +0000 From: Daniel Ehrenberg To: Martin Thomson Cc: wpack@ietf.org In-Reply-To: <0644699e-182b-4fc0-bcac-047f7bbdddec@www.fastmail.com> References: <712bcd2a77095b21c99851f4b22151f7@igalia.com> <0644699e-182b-4fc0-bcac-047f7bbdddec@www.fastmail.com> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <72102ce9f9d445fc38d3edc795fbacce@igalia.com> X-Sender: littledan@igalia.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Fri, 19 Feb 2021 20:26:45 -0000 Addressing resources from a bundle with "complete encapsulation" (e.g., a fragment relative to the bundle) could work for some cases better than others. However, there would be a large adoption cost to use such encapsulated URLs in general-purpose subresource loading from bundles. There's a large ecosystem of software oriented around identifying resources with today's URLs, where the fragment does not affect what's fetched, and where the scheme is expected to be http: or https: (e.g., HTML, DOM, build tooling, developers' code bases). For better loading performance, Web developers use "bundlers" to virtualize URLs and decouple what things are called from how they are fetched exactly [1]. Unfortunately, this virtualization makes the resulting resources and identifiers less visible to user agents. A standard bundling solution, using URLs like developers use today, could improve user agents' ability to see what is going on, both increasing their ability to make choices (e.g., content blocking) and be efficient (e.g., streaming/parallel processing without waiting for JS to set things up). To preserve the URL semantics and integrity, Brave proposed a mechanism of optional verification, which I'd like to adopt for subresource loading from bundles [2]. First, the idea is that, if a server responds with a bundle representing a URL, then the server must respond in the same way for a certain fetch of that URL [3]. Then, user agents may optionally verify a small percentage of their fetches served by bundles (either online or offline). In Brave's scheme, user agents may, at any time, decide to fetch individual URLs from the server instead of fetching from the bundle (e.g., if they have seen mismatches from this origin before). In this way, it is required and enforced that bundles' representation of HTTP responses for URLs is faithful, and it makes sense to refer to both with the same non-encapsulated URL. For certain limited cases, "complete encapsulation" works better. For example, I'm thinking about encapsulated URLs for JS modules with "module fragments" [4]. The idea here is to allow JS modules to be loaded without a separate network fetch, using a URL fragment. It's important to avoid the overhead in browsers of a network-level resource for JS modules since modern applications often have very many (order of 10k) JS modules in their original source. Virtualization at the JS module level is expected to be less costly than for fetched resources in general, since it is more narrow--only import statements need to be rewritten, not all network operations. About the scope/charter: I don't want to take anything about format, resource identification, security out of scope for discussion in this group, and it sounds like revisiting the charter was probably a mistaken basis to start this discussion on (sorry, I'm new to IETF). I'm excited to work in this WG to further dig into important questions about core semantics. I wrote up some ideas on the subresource serving case in more detail at [5]. (Sorry, it's even more wordy than the previous draft; I'm not really sure what to identify as the most core/relevant for this group.) Would people be interested in discussing subresource loading more at the upcoming IETF 110 WPACK WG meeting? Thanks, Dan [1] https://github.com/littledan/resource-bundles/blob/main/subresource-loading-tools.md#background-what-bundlers-do-today [2] https://github.com/littledan/resource-bundles/blob/main/subresource-loading.md#optionality-and-url-integrity [3] https://github.com/littledan/resource-bundles/blob/main/subresource-loading-server.md [4] https://github.com/littledan/proposal-module-fragments/ [5] https://github.com/littledan/resource-bundles On 2020-12-07 09:16, Martin Thomson wrote: > 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. > From nobody Fri Feb 19 17:27:29 2021 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 4574D3A0C00 for ; Fri, 19 Feb 2021 17:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Tc6qFj6WqcjR for ; Fri, 19 Feb 2021 17:27:25 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 BBB423A0BFD for ; Fri, 19 Feb 2021 17:27:25 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id a4so6357776pgc.11 for ; Fri, 19 Feb 2021 17:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=MX3mXpeA4S7U/uuPevOadzlFhKUeuW+KDx4vrRZUT6c=; b=LjzaiiW75Noza40NJnY6WGXRdNPFsv89HyIaoT/lc6unUvl1Y4SpYP8aTTilBlmJLh PePSx9+WJ9OqnVKjVDMJWsQoJLnVu4iCQgamRFO4bH7n7eOIZupNUKNyZXvJr1xm4LGS a4HwEYei3yuNaXTYZb3/LQUm0HdZ6Z5KTKpMolT7xWMvQINjQ2X6NhHD1F/5kPBtWE4V rMsPopYF4zBSZ6MerX9bAKbDvd0MJllQp2iePsx+6FxLhv1RpktzU5KiDsY4EtGI0zXI 7r/I9aQ8zztiRBf0JRZrwux7BVPD3l6Y+KqVYZVMxRAtgeJKiFahcZxm1ehoQY8z/b/Q 2mvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=MX3mXpeA4S7U/uuPevOadzlFhKUeuW+KDx4vrRZUT6c=; b=RosRdJ4CDjBg0uW7NraGKk9EN5wZ+UOMFjo6+/IvqmUJnhfsCpexS9WLyVPPWP+pDv Kg/k8ZWGVv5/SOP/WMHXLWUha5pIAtMEyZIQW7NA41e5Wc216QEGlW1bJgwThu0ce+u1 XO9iU7DSNYCPdO95cYdpdrMwMJdW44vFfrmQBZ78NR8K7EwDOaxuSizD1LUhEm8teK9H Pw5DHyqHWJrmMkNvCj0S7PiXm06cK+5DntZeVVcboz2G8l69pHoMizQGW8R9kH+O88dJ Bh5yxNOo89H576fNGO0jOn1OE60dmaDXTCgyoWE/vn4UqzgPmADFHzbm5QLkhJi6P3SZ KPwA== X-Gm-Message-State: AOAM533+0nVgC4bPq60So7F1YOVEaJ3v8Adfa5jh5MsKi5K2ffA2ZoTa aJFqzP6WGQO/rzG/Lihokqg= X-Google-Smtp-Source: ABdhPJx2B03zqaLoFk2Ur9shOtomLx87UMhHf8/UtwUDzmwCm5kvpB/lMMlegJwqP3fGh6txlFm/Ow== X-Received: by 2002:a62:1dcc:0:b029:1ed:6bc0:8cbf with SMTP id d195-20020a621dcc0000b02901ed6bc08cbfmr162423pfd.34.1613784445125; Fri, 19 Feb 2021 17:27:25 -0800 (PST) Received: from TVPC (c-73-158-116-21.hsd1.ca.comcast.net. [73.158.116.21]) by smtp.gmail.com with ESMTPSA id i10sm2128359pfq.95.2021.02.19.17.27.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Feb 2021 17:27:24 -0800 (PST) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Daniel Ehrenberg'" , References: In-Reply-To: Date: Fri, 19 Feb 2021 17:27:23 -0800 Message-ID: <00ec01d70727$8b142070$a13c6150$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKenezAWLlAi4wn27HUS6HbOtSRjgIyPJbmqL+AAGA= Content-Language: en-us Archived-At: Subject: Re: [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: Sat, 20 Feb 2021 01:27:27 -0000 Why don't you use HTTP range retrieval to access parts of a bundle? It's OK not to have URLs for the parts without an explicit reification. It seemed to work for PDF. -- https://LarryMasinter.net https://interlisp.org > -----Original Message----- > From: Wpack On Behalf Of Daniel Ehrenberg > Sent: Friday, February 19, 2021 11:54 AM > To: wpack@ietf.org > Subject: Re: [Wpack] Factoring out some parts of the Web Bundle format > > On 2020-12-01 15:47, Daniel Ehrenberg wrote: > > 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/subresourc > e- > > 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 > > I've filed a few PRs against Jeffrey's draft proposal to make these changes > [1][2][3]. What do you think? Should we follow up on this topic in the > upcoming IETF 110 WPACK WG meeting? > > Dan > > [1] https://github.com/WICG/webpackage/pull/617 > [2] https://github.com/WICG/webpackage/pull/618 > [3] https://github.com/WICG/webpackage/pull/619 > > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack From nobody Tue Feb 23 15:02:02 2021 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 CD74B3A0EB5 for ; Tue, 23 Feb 2021 15:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.818 X-Spam-Level: X-Spam-Status: No, score=-9.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.57, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 kXPGFqd6zh7h for ; Tue, 23 Feb 2021 15:01:58 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 A9D2C3A0ECB for ; Tue, 23 Feb 2021 15:01:05 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id 204so415650qke.11 for ; Tue, 23 Feb 2021 15:01:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y2VbEW9RAM1YcjDvg/oAP4Mp49UsAHCLamOxpEFmBsw=; b=DAPx0zMycqcZJKk8OXbGGuMhvu/JSvo9owGpfc0CXZgOTZISG7pbT03o10H4R4OSe4 cpZPIZGmW6RiWwQXuF0y/ILb/m3iS1LQSoFZw69qtvvXKRWKhktq1ar6482WkdKVihZv xOr2kN9vhrkkJPpmNn+LlPWYuhj5CMA/foC1w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y2VbEW9RAM1YcjDvg/oAP4Mp49UsAHCLamOxpEFmBsw=; b=Ee0Li7FNiVAZr1ttvCO5nzFPVzUb6LqpjB4Ik0nzUfRw82bniqS9EhDYrQqDEpjJYd iSSs/XHgHYx3qkEeZ6NOCA/q1Lw7+eTnLVFOv6kRHTzhG+VpVp5gYy77dTqaPEnNeDlm Rq5y+DjZ2M/zczKOCgOD7xHyVialgRWWQdDwpGlbM9QXBo5k/v5MwFFn6utAQ3donTzm YaqAnfPS7ewoJfEnXMjP8KAF+yPAiZCdHv6nTRZQ9xU0FVrFM+g8DxI94xoIQGMlIwIV HRFuhtjI2Rn6wBedUSdctgYH7fzVStBuAAcXYhBdB9mM3dwgTpfhY/4nMzulKaRPAWLT olvg== X-Gm-Message-State: AOAM532iWUvrYbWvSe48MgpXQ7M86RDtzTsovsW0AmbhUZNw1/IIZHLR VrKK+sOlF21qzvxIyh2PKyERI66fNkcUAV4MzdvWuQ== X-Google-Smtp-Source: ABdhPJzyOeT4LE3o+N13ugkGME8vwiIY1zYUAX1wmn0pCQv67q1EcUAM03cMXTM6+pH4ylde5FjM5Gdabtgl9kyXey4= X-Received: by 2002:a05:620a:102a:: with SMTP id a10mr29095721qkk.324.1614121264390; Tue, 23 Feb 2021 15:01:04 -0800 (PST) MIME-Version: 1.0 References: <00ec01d70727$8b142070$a13c6150$@acm.org> In-Reply-To: <00ec01d70727$8b142070$a13c6150$@acm.org> From: Jeffrey Yasskin Date: Tue, 23 Feb 2021 15:00:53 -0800 Message-ID: To: Larry Masinter Cc: Daniel Ehrenberg , WPACK List Content-Type: multipart/alternative; boundary="00000000000097046905bc08e47c" Archived-At: Subject: Re: [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, 23 Feb 2021 23:02:01 -0000 --00000000000097046905bc08e47c Content-Type: text/plain; charset="UTF-8" I'm not sure which part of Daniel's emails you're replying to, but I know of 2 reasons not to use HTTP range requests for bundles in general. 1) Ranges interact badly with content-encoded resources. That is, the range refers to the post-compression byte ranges, which aren't what's available in the index. We could avoid content-encoding the bundles, and instead content-encode individual subresources, but that loses cross-resource compression, which is a big reason to bundle things in the first place. Transfer-encoding would seem to be a solution, but nowadays that's only defined for HTTP/1.1: https://httpwg.org/http-core/draft-ietf-httpbis-messaging-latest.html#field.transfer-encoding . 2) If the client receives the index of a bundle, compares it to the cache, and then issues range requests for the pieces it doesn't have, we have to also figure out what the server is doing while it's waiting for those range requests to come in. I think it probably should keep sending the bundle linearly in order to avoid wasting time and in case the client isn't planning to send ranges, but then it will probably have sent parts of the bundle that it now also has range requests for. Should it send those as if the range request wasn't connected to a full-bundle request? Reorder those parts to the end of the multipart/byteranges response? Something else? There are probably answers here, but getting it right seems complicated. Jeffrey On Fri, Feb 19, 2021 at 5:27 PM Larry Masinter wrote: > Why don't you use HTTP range retrieval to access parts of a bundle? > It's OK not to have URLs for the parts without an explicit reification. > > It seemed to work for PDF. > > -- > https://LarryMasinter.net https://interlisp.org > > > -----Original Message----- > > From: Wpack On Behalf Of Daniel Ehrenberg > > Sent: Friday, February 19, 2021 11:54 AM > > To: wpack@ietf.org > > Subject: Re: [Wpack] Factoring out some parts of the Web Bundle format > > > > On 2020-12-01 15:47, Daniel Ehrenberg wrote: > > > 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/subresourc > > e- > > > 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 > > > > I've filed a few PRs against Jeffrey's draft proposal to make these > changes > > [1][2][3]. What do you think? Should we follow up on this topic in the > > upcoming IETF 110 WPACK WG meeting? > > > > Dan > > > > [1] https://github.com/WICG/webpackage/pull/617 > > [2] https://github.com/WICG/webpackage/pull/618 > > [3] https://github.com/WICG/webpackage/pull/619 > > > > _______________________________________________ > > Wpack mailing list > > Wpack@ietf.org > > https://www.ietf.org/mailman/listinfo/wpack > > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack > --00000000000097046905bc08e47c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not sure which part of Daniel's emails yo= u're replying to, but I know of 2 reasons not to use HTTP range request= s for bundles in general.

1) Ranges interact badly= with content-encoded resources. That is, the range refers to the post-comp= ression byte ranges, which aren't what's available in the index. We= could avoid content-encoding the bundles, and instead content-encode indiv= idual=C2=A0subresources, but that loses cross-resource compression, which i= s a big reason to bundle things in the first place. Transfer-encoding would= seem to be a solution, but nowadays that's only defined for HTTP/1.1:= =C2=A0https://httpwg.org/http-core/draft-iet= f-httpbis-messaging-latest.html#field.transfer-encoding.

=
2) If the client receives the index of a bundle, compares it to = the cache, and then issues range requests for the pieces it doesn't hav= e, we have to also figure out what the server is doing while it's waiti= ng for those range requests to come in. I think it probably should keep sen= ding the bundle linearly in order to avoid wasting time and in case the cli= ent isn't planning to send ranges, but then it will probably have sent = parts of the bundle that it now also has range requests for. Should it send= those as if the=C2=A0range request wasn't connected to a full-bundle r= equest? Reorder those parts to the end of the multipart/byteranges response= ? Something else? There are probably answers here, but getting it right see= ms complicated.

Jeffrey

On Fri, Feb 19, 2021 at 5:2= 7 PM Larry Masinter <LMM@acm.org> = wrote:
Why don&#= 39;t you use HTTP range retrieval to access parts of a=C2=A0 bundle?
It's OK not to have URLs for the parts without an explicit reification.=

It seemed to work for PDF.

--
= https://LarryMasinter.net https://interlisp.org

> -----Original Message-----
> From: Wpack <wpack-bounces@ietf.org> On Behalf Of Daniel Ehrenberg
> Sent: Friday, February 19, 2021 11:54 AM
> To: wpack@ietf.org=
> Subject: Re: [Wpack] Factoring out some parts of the Web Bundle format=
>
> On 2020-12-01 15:47, Daniel Ehrenberg wrote:
> > Hi WPACK WG,
> >
> > As I mentioned in the message "Broadening the WPACK WG chart= er", I'm
> > very interested in Web Bundles for subresource loading, e.g.,
> >
> https://github.com/WICG/web= package/blob/master/explainers/subresourc
> e-
> > loading.md . The Web Bundle format has a great architecture, in t= erms
> > of having an extensible set of sections, to permit various differ= ent
> > usage profiles.
> > This WG could use take advantage of this architecture in order to=
> > define a cleanly layered format. In particular, a few features ar= e not
> > used for subresource loading:
> > - primary URL: not meaningful, as the bundle is not being navigat= ed to
> > - manifest section: not used, similarly--the manifest should be l= inked
> > from the document which includes the subresources
> > - variants: not recommended, as content negotiation should be don= e
> > when deciding which bundle to include, to avoid wasteful download= s
> >
> > I think we can factor each of these features out from the core We= b
> > Bundles Internet-Draft and put them into a separate Internet-Draf= t
> > 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 secti= on,
> > like the manifest section.
> > - The primary URL and manifest sections should be factored out in= to
> > this other draft
> > - For variants, the story is a bit trickier, since it is integrat= ed
> > into the responses section. Honestly, I'm having trouble unde= rstanding
> > 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 Cli= ent
> > Hints or
> > UA) extends outside of the variants model, if I understand correc= tly.
> > Is there something else we can do to future-proof the binary form= at
> > for this support, rather than including this particular format in= the
> > core RFC?
> >
> > There are other additional sections which may be useful for some<= br> > > applications. For example, within build tooling, a section could = be
> > added to represent the dependency graph among subresources. So, W= eb
> > Bundles with this modified factoring would represent an excellent=
> > basis for a variety of uses.
> >
> > What do you think?
> >
> > Thanks,
> > Dan
>
> I've filed a few PRs against Jeffrey's draft proposal to make = these
changes
> [1][2][3]. What do you think? Should we follow up on this topic in the=
> upcoming IETF 110 WPACK WG meeting?
>
> Dan
>
> [1] https://github.com/WICG/webpackage/pull/617<= br> > [2] https://github.com/WICG/webpackage/pull/618<= br> > [3] https://github.com/WICG/webpackage/pull/619<= br> >
> _______________________________________________
> Wpack mailing list
> Wpack@ietf.org=
> https://www.ietf.org/mailman/listinfo/wpack

_______________________________________________
Wpack mailing list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo/wpack
--00000000000097046905bc08e47c-- From nobody Fri Feb 26 19:04:09 2021 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 B569F3A0A63 for ; Fri, 26 Feb 2021 19:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 4MdYLdc_0fJL for ; Fri, 26 Feb 2021 19:04:06 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 363DB3A0B02 for ; Fri, 26 Feb 2021 19:04:05 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id w19so11212300qki.13 for ; Fri, 26 Feb 2021 19:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=C9Ud+AVZsxlm1jZVJBT5opcRjXWL4vbM6Hn9lsxj5W0=; b=VN2MtVCVF+cQseVhOyoiBjePfT8fhmu6mApvGVg2ALWvH1yzb01DdYjdgxG/rb7w6G 07gmBkQ/80sMQLgkFmSwRgIl6KTvx+owWiKh9nEUHypEGXhSi+ZkayoKKpRkzPkBr+TV Psflm3u7SzVTmv31+cgoAr9ZJbVP9aumjo7QA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=C9Ud+AVZsxlm1jZVJBT5opcRjXWL4vbM6Hn9lsxj5W0=; b=oK0GOyAXnnToL9Er0TR1RCVqsrWDY/PRL+25TlEsshZj47qL2mBy6UosWwBud2xzBU DyiITQg57MQBst/hZCbdZQFCh1QwPWPo+Zjhz0t7pG2iX6yB+IPER+PcZees1EG6NMT9 IWrO2hA3qf0nnxf3z+KtErUsx/yvgV3hHLIYxkzhZpNSFSna8uzYK8LfP0sV66z0jKrd Q7Y77CUu1xrTHM6KrLPw0HOOZNFY31vV9rkS7f/pChjw7FZJNmATmj8K/x3tGFghf5k3 YZp8TsBn5ZVHMjr8mPLi+2JkL2RLUsphaRU37WmgFqj1Ebsh+QCmDecP9DdLySyqe7Ed uRzw== X-Gm-Message-State: AOAM5319wgq/r3PXmUzn6LHc64MHw55YkKsb46CHaHI1sikybeRI2OCV eR146lUkkkNKC8J/bBPL2gB8xVLI1y2xlv08 X-Google-Smtp-Source: ABdhPJzN2yyKi+cqZ68qVNCgjBlKgGUDMLKZ4G+ZPOiqa4V1yWoRyRNrgW68ne2YUxAcBpI9DgB/Yw== X-Received: by 2002:a37:67c5:: with SMTP id b188mr5671592qkc.131.1614395044572; Fri, 26 Feb 2021 19:04:04 -0800 (PST) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id u126sm7675193qkc.107.2021.02.26.19.04.03 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Feb 2021 19:04:04 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: Date: Fri, 26 Feb 2021 22:04:02 -0500 To: WPACK List X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: [Wpack] wpack@ietf110: meeting logistics 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: Sat, 27 Feb 2021 03:04:08 -0000 Hi! We have a 1-hour slot scheduled for Friday, March 12, 2021 @ = 1530-1630 UTC. Links for how to participate are found below. = Registration [1] is required for Meetecho (not sure about the Audio only = stream) and you need an IETF data tracker account for the CodiMD [2]. ### Meeting Information Meetecho (a/v and chat): https://meetings.conf.meetecho.com/ietf110/?group=3Dwpack&short=3D&item=3D= 1 Audio (only): http://mp3.conf.meetecho.com/ietf110/wpack/1.m3u CodiMD (notes): https://codimd.ietf.org/notes-ietf-110-wpack Cheers, spt (for the chairs) [1] https://www.ietf.org/how/meetings/110/ [2] https://datatracker.ietf.org/accounts/create/= From nobody Fri Feb 26 19:08:58 2021 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 28B6F3A0B9E for ; Fri, 26 Feb 2021 19:08:57 -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 (1024-bit key) header.d=sn3rd.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 j9oZ7OHzUYVT for ; Fri, 26 Feb 2021 19:08:55 -0800 (PST) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 687083A0B9B for ; Fri, 26 Feb 2021 19:08:55 -0800 (PST) Received: by mail-qv1-xf2a.google.com with SMTP id cw15so4790328qvb.11 for ; Fri, 26 Feb 2021 19:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=a9nWzCNHNgYEl6ns5BRfrN7wBEl8aRpjn8uxzbhkhZs=; b=ZRzFSsN45FAgKgq8xkgFZzNEeoVRfTg5ozGFmzoNpEDEI8xi3MtGITL/yw8NAJYvt4 VwyLvf4HA1wXYIGjHVO4Me2ZmjpAkK5Ew+vnGZdyLuz2e6eB6JlxpUQQhJMz5QtJZQF0 6nxFP26+oNDlHDqxa/gpF+AR+MPBtHzV2l/LQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=a9nWzCNHNgYEl6ns5BRfrN7wBEl8aRpjn8uxzbhkhZs=; b=sfpvgJb1LlQjQBKWa8CMSiZqrrhhVyHjuNT/up7q5ha2IlXDn6L4H5UlPuFPERF03/ uzxuBiI92Fy0kg4AMV5sqdIW2lf2spfL499VPhheFVUZfLxyMNjJhBSAznSNtYJrFvsX tK4LXBHq6BFbxBwDGBlShx460GWAQ20d8Jgy9YpV3NWunwsFlkGD6Wx+M2aOlkQvAJgD Myj950oKWyv9/Kw3DQ84M65WjRJM0datJdJv1lthfl/zOLmAvmxEnaDmkSLjmF4TZ4u5 UAM+0xLbY/hIGFaFIvyWDS/+lPQwDjqr2u4fP5hBJ9L5EnAia/XUdLyBV0z2rnK4Yiro FLtQ== X-Gm-Message-State: AOAM533QNuUsH56TV2wNbAACCmGV2DUbUpvNiDErXSI1QRYUmfW7kmw7 KXQzahB8pg6NlUetF2VyU6pzQ6eCBPcVy2PP X-Google-Smtp-Source: ABdhPJxUGzb76QMl4jWlmQOZnYoN9Syww7dtzHBLspH73kE2I3ddM3mEH/KWoEvHb7Hn8s+pgio9hw== X-Received: by 2002:a0c:8ec1:: with SMTP id y1mr5502355qvb.11.1614395334000; Fri, 26 Feb 2021 19:08:54 -0800 (PST) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id 126sm7962815qkn.70.2021.02.26.19.08.53 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Feb 2021 19:08:53 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: <73A6B09B-79A0-4408-B07C-6A6C0BCBB061@sn3rd.com> Date: Fri, 26 Feb 2021 22:08:52 -0500 To: WPACK List X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: [Wpack] wpack@ietf110: draft agenda 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: Sat, 27 Feb 2021 03:08:57 -0000 Hi! I think our goal for IETF 110 should be to see what, if anything, = needs change in [1][2] for that I-D to be considered a candidate for WG = adoption. At this point, it is the I-D on offer and unless another I-D = shows up shortly it seems like that we should focus our attention on it. = To that end, I have asked Jeffery to pull together some slides to setup = that discussion. Part of this will address PRs SS Daniel referred to the = other day. That=E2=80=99s the outline of the agenda I plan to post = shortly, but it can be bashed. I hope that all slides posted by Monday, March 8, 2021 so that everyone = will have a chance to review them by our session on Friday. Cheers, spt (for the chairs) [1] = https://www.ietf.org/archive/id/draft-yasskin-wpack-bundled-exchanges-03.t= xt [2] = https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.ht= ml= From nobody Sat Feb 27 02:52:35 2021 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 0702E3A167E for ; Sat, 27 Feb 2021 02:52:33 -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 TYKgNOgRyuqq for ; Sat, 27 Feb 2021 02:52:28 -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 186153A167C for ; Sat, 27 Feb 2021 02:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:MIME-Version; bh=JxElilnAPRSycFWGzl/GWyvpiILH8CqE85Ki0CcuP8o=; b=i5LG8j+0aL35MwHCcvzAQ3gITEqeR2qR5Njy0IIn3o6y4ez0w7GwCj3y7ngXOqYInjGKVSHjPTmiTkB8uoBeneiJvIwx/HVqqebz1yvAhARhj5XmW7oq7S4wjtJPJr7GZJLhaXjCvX7e4eyzO5n8LULnO21Ensy8VU1kHoE6YSF53r6aNoFAW1nhcE5ZAhfx9K3LazqHkF9LpYrhBNqu7TXp9P4GL8brNMCLjJlY2Wh9SugKrmQNVeRooiZcWg5C4K1EPldsYKmxRqf0FMQTaj8o0bIK324zSi3lUmcewsul93pOepyWhYy2vYmFuIjVQNBWfcPHSnG8fWzi2ka4dg==; 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 1lFxCy-0005ae-F5; Sat, 27 Feb 2021 11:52:24 +0100 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtps (Cipher TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim) id 1lFxCv-00075x-Sn; Sat, 27 Feb 2021 11:52:24 +0100 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.94) (envelope-from ) id 1lFxCq-00083F-EA; Sat, 27 Feb 2021 11:52:16 +0100 MIME-Version: 1.0 Date: Sat, 27 Feb 2021 10:52:16 +0000 From: Daniel Ehrenberg To: Sean Turner Cc: WPACK List In-Reply-To: <73A6B09B-79A0-4408-B07C-6A6C0BCBB061@sn3rd.com> References: <73A6B09B-79A0-4408-B07C-6A6C0BCBB061@sn3rd.com> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <7b76f85aa3e3e02fcaf18407bfeb0028@igalia.com> X-Sender: littledan@igalia.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Wpack] wpack@ietf110: draft agenda 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: Sat, 27 Feb 2021 10:52:33 -0000 Hi everyone, I'd also like to discuss the use case of bundles for accelerated subresource loading on the Web. This use case is identified as lower priority in our charter and Jeffrey's use cases document, but I believe that there is strong demand for it in the Web ecosystem, and that it could be widely implemented if we deliver a suitable bundle format and semantics. A priority for me is that the mechanism for subresource loading from bundles preserves important properties of URLs, e.g., as content blockers depend on. If there's time for such a discussion, I'd like to present on it. This use case partially motivates the changes in the bundle format that I proposed, so it all ties together. Dan On 2021-02-27 03:08, Sean Turner wrote: > Hi! I think our goal for IETF 110 should be to see what, if anything, > needs change in [1][2] for that I-D to be considered a candidate for > WG adoption. At this point, it is the I-D on offer and unless another > I-D shows up shortly it seems like that we should focus our attention > on it. To that end, I have asked Jeffery to pull together some slides > to setup that discussion. Part of this will address PRs SS Daniel > referred to the other day. That’s the outline of the agenda I plan to > post shortly, but it can be bashed. > > I hope that all slides posted by Monday, March 8, 2021 so that > everyone will have a chance to review them by our session on Friday. > > Cheers, > spt (for the chairs) > > [1] https://www.ietf.org/archive/id/draft-yasskin-wpack-bundled-exchanges-03.txt > [2] https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack