From nobody Tue Oct 5 05:01: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 4771C3A0917 for ; Tue, 5 Oct 2021 05:01:33 -0700 (PDT) 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 7PasZMEowMK0 for ; Tue, 5 Oct 2021 05:01:27 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 864353A0912 for ; Tue, 5 Oct 2021 05:01:27 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id q125so499000qkd.12 for ; Tue, 05 Oct 2021 05:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=UypH0bF2TQv7cf5ovogaSnQaqiWmxNFdECMoh5o1T04=; b=g2sciU54tb0qGRnazfoZhBRad+7R6T6P6Wv1Rc0+zTy5aFC5V9gmNr7i0vh7yHXonX xDr5H8kktD4ySY1Qjj5os81HzlENjg8vPazv19OzRcALi3pjV6TXWatpZ+hTibxE7XIw UBn1ZkG6jXLFStPVfl087zJ4VP4tIyVhnbQ/s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=UypH0bF2TQv7cf5ovogaSnQaqiWmxNFdECMoh5o1T04=; b=Gqts3EeHGl+TE6jrT2KaQvOK+VMMDHBOQFfGMuPW7BfgLXZyZYD1feXoTwY5eJjdHy /c2E4EGDJnsTnINVxQceOsum7j6LgVIDiywuS1NFCTLNz7BW5EhnsWy0YouUXshb8ME6 PLpBGcWn01yR1JBV13lqRKxZ7rO1Q/MOyDEIV5eO1ldm389lw+3wh1jEqqwnk2jaFUoe Bigl3v2dOfNF3nrBfZz/yDfKhWbwd+CTAiUIDd2WCUoKeXj1FqGyFohSJz9t5j+xrY+T D7yUCJnPZf/B2jYmMeyJeUIXydTcMQOQWQz/hh+BtNOiV8uYRrHGq45qtm3i9amje4Jh /JBA== X-Gm-Message-State: AOAM530OVhyUrtlKmIKLbhL+uqYP67oRvF9O/s3dH/Q0Bu6zhzCRly6l QnVcGn+9G87LcB/ywZG5ClXws2rFzqSSZg== X-Google-Smtp-Source: ABdhPJxPTGFVpEPb8meCJP+ZYWHQ0ekICJpbdh+Y15gmsKVgX5UtFjpEV2Qlw12hcSN8x5ywbDtteA== X-Received: by 2002:a05:620a:5fd:: with SMTP id z29mr14422855qkg.36.1633435285707; Tue, 05 Oct 2021 05:01:25 -0700 (PDT) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id x18sm9319487qkx.94.2021.10.05.05.01.24 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Oct 2021 05:01:25 -0700 (PDT) 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.120.0.1.13\)) Date: Tue, 5 Oct 2021 08:01:24 -0400 References: <01A247EA-B07D-4C7D-91DA-33D2A1658645@sn3rd.com> To: WPACK List In-Reply-To: <01A247EA-B07D-4C7D-91DA-33D2A1658645@sn3rd.com> Message-Id: <2995B948-0CE5-4606-9595-50BF5987BA3B@sn3rd.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Wpack] Call for adoption of draft-yasskin-wpack-use-cases (redux) 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, 05 Oct 2021 12:01:34 -0000 Hi! The chairs are going to declare that is very rough consensus to adopt = this I-D as a WG item. We are basing this on the lively discussions = during our IETF 111 session and the weak-ish support on the mailing = list. We will note a couple of things 1) there is no intent to publish = this I-D as an RFC, as per the charter; 2) draft-yasskin-wpack-use-cases = is the starting point and will be revised to keep the near-term use = cases with consensus in the main body and the long-term use cases = without consensus in an appendix. Cheers, spt (for the chairs) > On Aug 18, 2021, at 22:14, Sean Turner wrote: >=20 > Hi! This message starts a WG call for adoption of = draft-yasskin-wpack-use-cases. This is the 2nd WG call for adoption for = this I-D; the 1st WG call for adoption did not garner enough interest = for the chairs to make a decision, but at IETF 111 the WG discussed = adopting the I-D and trimming it down version to only agreed use cases = (and sticking the others in an appendix). The I-D can be found here: > https://datatracker.ietf.org/doc/draft-yasskin-wpack-use-cases/ >=20 > This adoption call will run until 10 September 2021 at 2359 UTC.* = Please indicate whether or not you would like to see this I-D adopted as = a WG item. >=20 > Thanks, > Sean and Dave >=20 > * Note that I am allowing a little extra time here because it is = vacation time. From nobody Tue Oct 5 12:18: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 DA2953A0953 for ; Tue, 5 Oct 2021 12:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 WRv4rQUN_H4C for ; Tue, 5 Oct 2021 12:18:50 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 14EF23A0958 for ; Tue, 5 Oct 2021 12:18:50 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id g10so800985edj.1 for ; Tue, 05 Oct 2021 12:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=VBsT/pdTk8DwlF1FYmUwQmnv8JR4XKlqBpdcW32u7u4=; b=MI9gYqlRyfhdaKCkq1Ta70BwtlmsgshJNfhsuudVYn2ppK4Gd0G079D9kvpVMKMF7l mtJKmXrdazwMVAGnLYJw9deu1/VOYZlBGGd/qFfj1+verE/I1Z76ct0/xotpLwo/ZF35 u70sR++nFsWTHnthgZ7FXvJrzgEfIXGApaQ58aC0KIYArY9Vow2tUE5kkHbol0NCFa2/ H6Yn5jSK3HGrSjwAaA+48kmjBWJ3XB83HfwleeMcyKwS9buaiNDVUyuSkumAOv/kWVjX Mp5OFn2t7EssHk3cRC7gaSzZptFNwMIE0dMcNgnNoo5dOSbjstT5EG3w7PGVG04D/Dd5 PF8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VBsT/pdTk8DwlF1FYmUwQmnv8JR4XKlqBpdcW32u7u4=; b=D+jgBMpDfj4yxzvvH64iX0LD3DVYiceKvH3Q5AsK1gm0/62mQRAnWKTiQLEzKcrPTQ FtP/q0PdPID+y5cm58rNgSZb5NTAg4Kk7LQT3LhmriqOR1c1B40mcG6mnFVyJmwI72MV e6j1m2lGJCKsw4br1n1li2mQtYp75K9OvuAU+i40YguRm4NFt4ETfPPrjw7s4S/qHdnp SV4NSL/yO8X064jldfOk/4yZuvOZ1GflODlKcBOBxhbk/DgGKQhLzaOP2FW9mYZWnWVW 64bTwaJXi/D40CL/6OcEJk2slbzj9x3RuhX36t3uAXJV2HewmyDOQxrr9DuWiF2iGB8o hC6w== X-Gm-Message-State: AOAM531uptGv0mKeaRQ0GTU+KN6Cf99wNU/0zlMt/rSd0URiWikqON8w X4mZKHL044s4My833bosYP1pj7GsaHJU9ymNRatO4faoB2U= X-Google-Smtp-Source: ABdhPJxtGyk6ASKjrhPv5nugpheu8chGiaxJ5mq5i7bY9MJloAvzmrH8HYmJi7UgbXoJV0/bmqYY76CaxA6aRNpaz4o= X-Received: by 2002:a17:906:6d0a:: with SMTP id m10mr26476255ejr.90.1633461527944; Tue, 05 Oct 2021 12:18:47 -0700 (PDT) MIME-Version: 1.0 From: Ilya Kreymer Date: Tue, 5 Oct 2021 12:18:37 -0700 Message-ID: To: WPACK List Content-Type: multipart/alternative; boundary="00000000000020a09e05cd9fe645" Archived-At: Subject: [Wpack] WPACK and Web Archiving-focused 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, 05 Oct 2021 19:18:55 -0000 --00000000000020a09e05cd9fe645 Content-Type: text/plain; charset="UTF-8" Hello, We would like to start the process of standardizing a format that fully supports all the requirements for bundling web data, http request/response pairs, page lists, and associated metadata for web archiving use cases, a 'web archive bundle' format. I wanted to inquire if the WPACK working group would be the right place for introducing such an effort, or if it would be out of scope. Looking at the charter, there is definitely overlap with some, but not all of the goals. In particular, the bullet points #1, 2, 3, 5 from https://datatracker.ietf.org/doc/charter-ietf-wpack/ are shared goals of the web archiving bundle format, while some of the other goals are less important. The current CBOR-based bundle proposal is not sufficient to address the full scope of web archiving requirements, and that's totally fine, as key goals for that format are quite different. I am wondering if this group would be open to accepting a proposal for a different standard specifically geared towards addressing all of the web archiving use cases, or if we should pursue other paths, such as other working groups/new working group within IETF for such standardization efforts. Here is a (very) brief summary of some of the requirements for web archiving that will be fulfilled in this new format: - forwards and backwards compatibility with existing ISO WARC format, which will be used to store the raw http request/response data. - an index based on URL + timestamp - index support for multiple request/response pairs of same URL, at same or different timestamp - support for storing request body, eg. for POST requests - random-access based URL+timestamp index that can be partially loaded via random access. - support for different size web archive bundles, from a single page to very large archive bundles consisting of many GBs of data or hundreds of pages that are loaded entirely via random access. - support for text index to allow full-text search - support for combining multiple web archive bundles for a growing web archive collection. We of course plan to elaborate on all of these but first want to understand if this group would be the appropriate place for this work, or not. Any advice/additional guidance on this would be appreciated, or any next steps to pursue this effort, if this is the right place for this work. Thank you, Ilya Webrecorder --00000000000020a09e05cd9fe645 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

We would like to start the proce= ss of standardizing a format that fully supports all the requirements for b= undling web data, http request/response pairs, page lists, and associated m= etadata for web archiving use cases, a 'web archive bundle' format.= I wanted to inquire if the WPACK working group would be the right place fo= r introducing such an effort, or if it would be out of scope.
Looking at the charter, there is definitely overlap with some, = but not all of the goals. In particular, the bullet points #1, 2, 3, 5 from= https://d= atatracker.ietf.org/doc/charter-ietf-wpack/ are shared goals of the web= archiving bundle format, while some of the other goals are less important.=

The current CBOR-based bundle proposal is not suf= ficient to address the full scope of web archiving requirements, and that&#= 39;s totally fine, as key goals for that format are quite different.
<= div>
I am wondering=C2=A0if this group would be open to accep= ting a proposal for a different standard specifically geared towards addres= sing all of the web archiving use cases, or if we should pursue other paths= , such as other working groups/new working group within IETF for such stand= ardization efforts.

Here is a (very) brief summary= of some of the requirements for web archiving that will be fulfilled in th= is new format:
- forwards and backwards compatibility with existi= ng ISO WARC format, which will be used to store the raw http request/respon= se data.
- an index based on URL + timestamp
- index su= pport for multiple request/response pairs of same URL, at same or different= timestamp
- support for storing request body, eg. for POST reque= sts
- random-access based URL+timestamp index that can be partial= ly loaded via random access.
- support for different size web arc= hive bundles, from a single page to very large archive bundles consisting o= f many GBs of data or hundreds of pages that are loaded entirely via random= access.
- support for text index to allow full-text search
- support for combining multiple web archive bundles for a growing= web archive collection.

We of course plan to elab= orate on all of these but first want to understand if this group would be t= he appropriate place for this work, or not.

Any ad= vice/additional guidance on this would be appreciated, or any next steps to= pursue this effort, if this is the right place for this work.

Thank you,
Ilya
Webrecorder
=


--00000000000020a09e05cd9fe645-- From nobody Tue Oct 5 15:36:51 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 625DD3A0C0E for ; Tue, 5 Oct 2021 15:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 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.001, HTML_MESSAGE=0.001, 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 ELpBGFW3IdgH for ; Tue, 5 Oct 2021 15:36:42 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 981423A0C42 for ; Tue, 5 Oct 2021 15:36:42 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id a11so479789plm.0 for ; Tue, 05 Oct 2021 15:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=RsmXhGdBLXiudAawl621DkS5amrP2fLDud7WzDyPN9Y=; b=LMsj8e82j5Fi9hocM23ig9PyxkgZ7OkApT3VJ6kKFftYiO7P5lF1rXyWQ93sot3WKM BKKGaUybWO5WYJFb4Q1eswix3aO83d90RYraRForyyUVDzkQqjBXc/kFCYAHOUcMLGx/ xdrOpLs4VKPqVe4YX76H/IUMpItJAUKvO5gpaBwFA1herbFr4pze+15CxI1z9+KNy7T+ at7UJ4d6+DlcQjiQX9NFsZvpZSxCpo8IunnqRpd5V5QbPhjj5iXZYOAzqoYF6YzU5L47 wzsxa3X2ZTCAGM88+mQ5E7wEsfxUbr6/gred/7ew89hjKaAMAt5i7xPqFVNQj8SwOkos dQqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-language:thread-index; bh=RsmXhGdBLXiudAawl621DkS5amrP2fLDud7WzDyPN9Y=; b=cPPBPJenZCYck4pTFllbE7/HnToLqfgcfjHa8UjpMKX985HOYPNdmU6ByVxQLnIHHN wSAEvx7mj2YLgeg09NVLtyAG80NGsJJnD2BPxBy+bI9H+ra3RzSLlnVgGnYCYZ2MzOit zqTOd6gvEIvCpQidUmOESwep+1W+hG0VXKPl3f/YR7jzccRBaZUWwTxEE12IefwgPgWq SJ2snNdU0lYQbqmuNgvhGw1YZ2Q+DAfkk358uYsJRmWkxUI1JXKqqZH5fDkpDOzTzKCk n92mYmGpwsXha2WK8r5ztc1O8hBugmuX0pLD6GwgmdblQyyx4S4UM8o2upVPEztxirJ3 /Etw== X-Gm-Message-State: AOAM531FQyjUFiO64BZhcBJkGXjRruX9e9UJfEEQ0P8OPQuYwnzyqEI6 7+TnV/IN8nEiFOWD1SSLUGQ= X-Google-Smtp-Source: ABdhPJwDl2nvhMBykMTVR0T69951o2UTKid8PEBf1vpBZ0DIHnlJEwdSknAGiEp67KktPLlPGOzvow== X-Received: by 2002:a17:902:9303:b029:12c:29c:43f9 with SMTP id bc3-20020a1709029303b029012c029c43f9mr7679767plb.5.1633473401678; Tue, 05 Oct 2021 15:36:41 -0700 (PDT) Received: from TVPC (c-73-158-116-21.hsd1.ca.comcast.net. [73.158.116.21]) by smtp.gmail.com with ESMTPSA id c140sm6649262pfc.31.2021.10.05.15.36.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Oct 2021 15:36:40 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Ilya Kreymer'" Cc: "'WPACK List'" References: In-Reply-To: Date: Tue, 5 Oct 2021 15:36:40 -0700 Message-ID: <00a801d7ba39$777caa80$6675ff80$@acm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01D7B9FE.CB1EBCE0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQH3Ecn8IULE/INtr29jquhQMNd21auGR3Fg Archived-At: Subject: Re: [Wpack] WPACK and Web Archiving-focused 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, 05 Oct 2021 22:36:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A9_01D7B9FE.CB1EBCE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable A modest proposal missing the =F0=9F=98=8A smiley.=20 =20 -- https://LarryMasinter.net = https://interlisp.org =20 From: Wpack On Behalf Of Ilya Kreymer Sent: Tuesday, October 5, 2021 12:19 PM To: WPACK List Subject: [Wpack] WPACK and Web Archiving-focused bundle format =20 Hello, =20 We would like to start the process of standardizing a format that fully = supports all the requirements for bundling web data, http = request/response pairs, page lists, and associated metadata for web = archiving use cases, a 'web archive bundle' format. I wanted to inquire = if the WPACK working group would be the right place for introducing such = an effort, or if it would be out of scope. =20 Looking at the charter, there is definitely overlap with some, but not = all of the goals. In particular, the bullet points #1, 2, 3, 5 from = https://datatracker.ietf.org/doc/charter-ietf-wpack/ are shared goals of = the web archiving bundle format, while some of the other goals are less = important. =20 The current CBOR-based bundle proposal is not sufficient to address the = full scope of web archiving requirements, and that's totally fine, as = key goals for that format are quite different. =20 I am wondering if this group would be open to accepting a proposal for a = different standard specifically geared towards addressing all of the web = archiving use cases, or if we should pursue other paths, such as other = working groups/new working group within IETF for such standardization = efforts. =20 Here is a (very) brief summary of some of the requirements for web = archiving that will be fulfilled in this new format: - forwards and backwards compatibility with existing ISO WARC format, = which will be used to store the raw http request/response data. - an index based on URL + timestamp - index support for multiple request/response pairs of same URL, at same = or different timestamp - support for storing request body, eg. for POST requests - random-access based URL+timestamp index that can be partially loaded = via random access. - support for different size web archive bundles, from a single page to = very large archive bundles consisting of many GBs of data or hundreds of = pages that are loaded entirely via random access. - support for text index to allow full-text search - support for combining multiple web archive bundles for a growing web = archive collection. =20 We of course plan to elaborate on all of these but first want to = understand if this group would be the appropriate place for this work, = or not. =20 Any advice/additional guidance on this would be appreciated, or any next = steps to pursue this effort, if this is the right place for this work. =20 Thank you, Ilya Webrecorder =20 =20 =20 ------=_NextPart_000_00A9_01D7B9FE.CB1EBCE0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

A modest proposal missing the 😊 = smiley.

 

--

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

 

From: Wpack = <wpack-bounces@ietf.org> On Behalf Of Ilya = Kreymer
Sent: Tuesday, October 5, 2021 12:19 PM
To: = WPACK List <wpack@ietf.org>
Subject: [Wpack] WPACK and = Web Archiving-focused bundle format

 

Hello,

 

We would like to start the process of standardizing a = format that fully supports all the requirements for bundling web data, = http request/response pairs, page lists, and associated metadata for web = archiving use cases, a 'web archive bundle' format. I wanted to inquire = if the WPACK working group would be the right place for introducing such = an effort, or if it would be out of scope.

 

Looking at the charter, there is definitely overlap = with some, but not all of the goals. In particular, the bullet points = #1, 2, 3, 5 from https://dat= atracker.ietf.org/doc/charter-ietf-wpack/ are shared goals of the = web archiving bundle format, while some of the other goals are less = important.

 

The current CBOR-based bundle proposal is not = sufficient to address the full scope of web archiving requirements, and = that's totally fine, as key goals for that format are quite = different.

 

I = am wondering if this group would be open to accepting a proposal = for a different standard specifically geared towards addressing all of = the web archiving use cases, or if we should pursue other paths, such as = other working groups/new working group within IETF for such = standardization efforts.

 

Here is a (very) brief summary of some of the = requirements for web archiving that will be fulfilled in this new = format:

- forwards and = backwards compatibility with existing ISO WARC format, which will be = used to store the raw http request/response = data.

- an index based on = URL + timestamp

- index = support for multiple request/response pairs of same URL, at same or = different timestamp

- = support for storing request body, eg. for POST = requests

- random-access = based URL+timestamp index that can be partially loaded via random = access.

- support for = different size web archive bundles, from a single page to very large = archive bundles consisting of many GBs of data or hundreds of pages that = are loaded entirely via random access.

- support for text index to allow full-text = search

- support for = combining multiple web archive bundles for a growing web archive = collection.

 

We of course plan to elaborate on all of these but = first want to understand if this group would be the appropriate place = for this work, or not.

 

Any advice/additional guidance on this would be = appreciated, or any next steps to pursue this effort, if this is the = right place for this work.

 

Thank you,

Ilya

Webrecorder

 

 

 

------=_NextPart_000_00A9_01D7B9FE.CB1EBCE0-- From nobody Wed Oct 6 08:55: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 915223A1E6E for ; Wed, 6 Oct 2021 08:55:43 -0700 (PDT) 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 0qFzIWHiGQJk for ; Wed, 6 Oct 2021 08:55:38 -0700 (PDT) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 5D1583A1E68 for ; Wed, 6 Oct 2021 08:55:38 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id m13so1175302qvk.1 for ; Wed, 06 Oct 2021 08:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mra1pnZSq4F5BsnozzE42PkYzq/SJhd6JmMhMlQlppw=; b=CHEAHPZARiZlGlMO41UVf+ucb3lIPu76kkHGMQm+S1hzTs+V2R+WoPFBbsUszPKALO ZwUtECXxZqKkACiDJ37y8az7gKvPmBzlLmxmXlvlyB4AK9X512EIgXGTwQz0uC/1Rd0m 5+tcdmyYQ0Lquicf7pv+Fl1f5hB08fDPHUEng= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mra1pnZSq4F5BsnozzE42PkYzq/SJhd6JmMhMlQlppw=; b=bieOqhQXLUkDbwQuY/z+MJlPU6Gs9iZ11UB1NVnBidNG3tuE1ACXIwG9eENtB8WQ7U dMk2kKF8QvndAtgMTA1Fawbt1nuXAKD6QzN8Z5JkqXhTiwjqUn48XqtxEiFtaLf9PIS1 jtp6v8MzK1xMqAv8A+JHgwU9XdxOSaKJKag7uRdfhJaBPKw2ta1d+43CmAX7C9TDg2dr /DHMeLSaOkN9sNy28n0LtJN1WxX5VXYrRl1pCQ+Ks8DxME+snJkMDX/AUlLtCEVGFJdZ 6gvo8ynCPyZ9pUoKbME+Y/2++EFAE+Is/mSspMVCSGCumKMIvCQQXz7iPzklF4ZbWWq1 nxpg== X-Gm-Message-State: AOAM530ApvJTLZowNC9l5D/kr+ooSYGVbVN4tkF7t+USH4EFv6lpWOej +qx7jtYrlLtQjFCdOO4SCt1fyph/0AmuXQ== X-Google-Smtp-Source: ABdhPJxyWRhpm8tzm4f9QOnpzb4WlPDumV3HAEwJ4ryqcrvgB6TGKQNAaJ5S66Rz74crERpjFGfMiA== X-Received: by 2002:a0c:e183:: with SMTP id p3mr34011382qvl.65.1633535736922; Wed, 06 Oct 2021 08:55:36 -0700 (PDT) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id n16sm13918166qta.51.2021.10.06.08.55.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Oct 2021 08:55:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sean Turner In-Reply-To: Date: Wed, 6 Oct 2021 11:55:35 -0400 Cc: WPACK List Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ilya Kreymer X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Wpack] WPACK and Web Archiving-focused 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: Wed, 06 Oct 2021 15:55:44 -0000 Illya, With my chair hat on: =46rom a purely procedural perspective, adopting work that is beyond = what WPACK is chartered for would be considered out of scope. To do this = new work, WPACK we would need to recharter. Rechartering is not out of = the question, but getting that process kicked off involves some = additional mechanics. The process would likely start with a proposal to the DISPATCH WG = [0][1]. DISPATCH is where new work in the ART area is evaluated. After = discussing the work, DISPATCH can recommend a number of paths from = suggesting that the new work be added to an existing WG or suggesting = that a new WG be formed to address the work as well as rejecting the = work entirely. The best bet to make sure that discussion goes as = smoothly as possible is to have an I-D ready to go that people can read = and comment on. I hope that helps with respect to the process of getting new work = adopted. With my chair hat off: I do not have access to the WARC IS (ISO 28500:2017), but I found [2], = and that made me wonder about the following (I have no doubt these = questions would also come up during dispatch discussions or maybe not = because everybody but me knows the answer): - If there is already an ISO IS for the WARC format, then why is an RFC = needed? I am asking this primarily because the IETF and ISO (through = ISOC) have a Class A liaison [3]. Part of that agreement is that we will = not produce duplicative work. - If there is already and ISO IS and it is a hard requirement maintain = compatibility with the ISO WARC format, then what work is left to be = done? - What are the differences between ISO 28500:2017 and [2]. - Is there any reason ISO/IIPC has not already registered the = application/warc and application/warc-fields media types with IANA. I = could not find them in the list [4]. spt [0] Honestly, the proposal starts with you trying to get folks = interested in your idea and that=E2=80=99s how I interpret this email ;) [1] https://datatracker.ietf.org/wg/dispatch/about/ [2] = https://iipc.github.io/warc-specifications/specifications/warc-format/warc= -1.1/ [3] https://www.iso.org/organization/9418.html [4] = https://www.iana.org/assignments/media-types/media-types.xhtml#application= > On Oct 5, 2021, at 15:18, Ilya Kreymer wrote: >=20 > Hello, >=20 > We would like to start the process of standardizing a format that = fully supports all the requirements for bundling web data, http = request/response pairs, page lists, and associated metadata for web = archiving use cases, a 'web archive bundle' format. I wanted to inquire = if the WPACK working group would be the right place for introducing such = an effort, or if it would be out of scope. >=20 > Looking at the charter, there is definitely overlap with some, but not = all of the goals. In particular, the bullet points #1, 2, 3, 5 from = https://datatracker.ietf.org/doc/charter-ietf-wpack/ are shared goals of = the web archiving bundle format, while some of the other goals are less = important. >=20 > The current CBOR-based bundle proposal is not sufficient to address = the full scope of web archiving requirements, and that's totally fine, = as key goals for that format are quite different. >=20 > I am wondering if this group would be open to accepting a proposal for = a different standard specifically geared towards addressing all of the = web archiving use cases, or if we should pursue other paths, such as = other working groups/new working group within IETF for such = standardization efforts. >=20 > Here is a (very) brief summary of some of the requirements for web = archiving that will be fulfilled in this new format: > - forwards and backwards compatibility with existing ISO WARC format, = which will be used to store the raw http request/response data. > - an index based on URL + timestamp > - index support for multiple request/response pairs of same URL, at = same or different timestamp > - support for storing request body, eg. for POST requests > - random-access based URL+timestamp index that can be partially loaded = via random access. > - support for different size web archive bundles, from a single page = to very large archive bundles consisting of many GBs of data or hundreds = of pages that are loaded entirely via random access. > - support for text index to allow full-text search > - support for combining multiple web archive bundles for a growing web = archive collection. >=20 > We of course plan to elaborate on all of these but first want to = understand if this group would be the appropriate place for this work, = or not. >=20 > Any advice/additional guidance on this would be appreciated, or any = next steps to pursue this effort, if this is the right place for this = work. >=20 > Thank you, > Ilya > Webrecorder >=20 >=20 >=20 > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack From nobody Wed Oct 6 10:43:18 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 1B4783A090D for ; Wed, 6 Oct 2021 10:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 E1evFhCVlh3K for ; Wed, 6 Oct 2021 10:43:02 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 3E9C63A08D3 for ; Wed, 6 Oct 2021 10:43:00 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id b78so3768053iof.2 for ; Wed, 06 Oct 2021 10:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ijFugzZFNSUIvlFQTXHTUKK50yxTRtnF1Nz1ts6+gx8=; b=UofJLukPZwl+Af5Fy8yRgkLjTQgjmdoUntqC1rKUK0cwhgMzRqwY2mgcbOB7ISHRv2 4wDzySCjaVhLrVZIKN3VghVdkGZs8DJe6WLNknwFkikeXPX4J2PDXI9iVz7B6LNZywH7 5epA3/sHKLmebGQd9fxUA0AdvA7Ie+ZEUhCOd/gzpdc1dnH1/nBif5q2NXa8O07ra37Y cl+wlUy02Ehb3OuqRgQGQ/qkn33DE7iR8c11HUqfA3Nt6ssHk8WvTg8+38NXzkaHFOP2 QIkhi1rZh8lny7DNs1M3YownpNzkoF3tvLI0se9R/B+XsOF+Gf/G9q6XHZO3x49p+mPF FG0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ijFugzZFNSUIvlFQTXHTUKK50yxTRtnF1Nz1ts6+gx8=; b=1FCubo+laKobSXiWVhoKz2jBJwMglaYkjLf7pjCzPecJ63djsLDy43QG+Btr8rSIg6 FiYO0NJ+bCIF34+c6VwLnYfB3jTHRt1FIk/sQfbnoYysRcVbI35+Hi0XXD3dscq6/ewX VjNxnQkWDwcyCeerMMOPDK8yyA8UnNdY29ka2mJGnsEWDlG0OafbyURl5qdwn2/82qJ5 gVEOXJke0liUASCjtaeHtnRG60ziAx2wSNNmJh7msVeU6/HG7/lsI7nTeroqNKH8vfLE 3QKsPMbaIc7Q1Qrum2frWbisL7qhf4PE6B0qlP1UgE9GXrEYS2COn+HAarcaB+8Hnq/U T+vw== X-Gm-Message-State: AOAM532FoBhicPxe7kk54OXi8vGnh2A6UZ1QLnubwYegcTfZptwq+78/ Ra/jO1kMhTmeuTNBPoW3BeEnbjvKaAbjnVo/ti8kZ09GhiU= X-Google-Smtp-Source: ABdhPJzlysbVs+NiwZIBIh9wHpJ6CuxIVIJX4fNzU3GfYeuE77nJSaD310Jel2igA8/VpdfWbScVKJGeQ0oI538Z4dc= X-Received: by 2002:a02:6048:: with SMTP id d8mr8113840jaf.61.1633542179112; Wed, 06 Oct 2021 10:42:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ilya Kreymer Date: Wed, 6 Oct 2021 10:42:47 -0700 Message-ID: To: Sean Turner Cc: WPACK List Content-Type: multipart/alternative; boundary="0000000000004fca3705cdb2ad47" Archived-At: Subject: Re: [Wpack] WPACK and Web Archiving-focused 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: Wed, 06 Oct 2021 17:43:16 -0000 --0000000000004fca3705cdb2ad47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sean, Thanks for the quick response! My responses below: On Wed, Oct 6, 2021 at 8:55 AM Sean Turner wrote: > Illya, > > With my chair hat on: > > From a purely procedural perspective, adopting work that is beyond what > WPACK is chartered for would be considered out of scope. To do this new > work, WPACK we would need to recharter. Rechartering is not out of the > question, but getting that process kicked off involves some additional > mechanics. > > The process would likely start with a proposal to the DISPATCH WG [0][1]. > DISPATCH is where new work in the ART area is evaluated. After discussing > the work, DISPATCH can recommend a number of paths from suggesting that t= he > new work be added to an existing WG or suggesting that a new WG be formed > to address the work as well as rejecting the work entirely. The best bet = to > make sure that discussion goes as smoothly as possible is to have an I-D > ready to go that people can read and comment on. > > I hope that helps with respect to the process of getting new work adopted= . > Thank you for clarifying that it would be out of scope as chartered now (I wasn't quite sure as there are several overlapping goals) and the steps needed for moving forward. > > > With my chair hat off: > > I do not have access to the WARC IS (ISO 28500:2017), but I found [2], an= d > that made me wonder about the following (I have no doubt these questions > would also come up during dispatch discussions or maybe not because > everybody but me knows the answer): > > - If there is already an ISO IS for the WARC format, then why is an RFC > needed? I am asking this primarily because the IETF and ISO (through ISOC= ) > have a Class A liaison [3]. Part of that agreement is that we will not > produce duplicative work. > - If there is already and ISO IS and it is a hard requirement maintain > compatibility with the ISO WARC format, then what work is left to be done= ? > > - What are the differences between ISO 28500:2017 and [2]. > > - Is there any reason ISO/IIPC has not already registered the > application/warc and application/warc-fields media types with IANA. I cou= ld > not find them in the list [4]. > Apologies if the goals weren't made clear. The intent is not to modify WARC in any way, but introduce a way of packaging WARC files to make them more usable. The goal is to make web archives loadable (and creatable) via web browsers. The WARC format alone is not suitable for loading in the browser, due to a lack of index and other metadata (pages, etc...). However, it contains all of the http request and response data in a well-established format. There is a well established existing ecosystem of tools around WARC ( https://github.com/iipc/awesome-web-archiving), and many PBs of data in WARC files. This idea boils down to the following: to bundle WARC files, along with other data into a ZIP (or ZIP64) file. This allows for storing WARC files unaltered, plus adding a random-access index and other requisite data to the ZIP file. The ZIP format (and ZIP64) are already random access readable. While ZIP and WARC of course have their flaws, this simply combines two well-established formats to solve a number of problems related to web archives in browsers. Since this bundle format is a ZIP containing WARCs, the 'backwards compatibility with WARC' becomes as trivial as: unzip /path/to/warc and users get a standard WARC that is compatible with existing ecosystem of tools. The forwards compatibility is that if/when a new ISO WARC format is introduced, it can also be bundled in the same way. The WARC format itself is fully orthogonal to the bundling of the WARC in the ZIP. This proposal would be about defining the contents and layout of the files inside the bundled ZIP, one of which will be files of type WARC. Other formats will need to be more formally defined. I wanted to offer a very specific, but common example, relating to "2.1.3 Save and Share a web page" that was adopted as part of draft-yasskin-wpack-use-cases. Suppose a user wants to save a web page that contains two or more embedded YouTube videos. YouTube currently uses POST requests to the same URL, differing only by request payload. To fully replay such a page, it is necessary to save the request payload, and match the payload in the lookup when determining which video to load where. Unfortunately, the CBOR-based bundle specification will be unable to deal with this use case, because request payloads are not saved. The web archive bundle proposal will address this use case (and others) by storing the data as WARC and specifying the necessary steps to include the POST data in the lookup index. Of course, it'd be better if YouTube didn't do this, but we have to work with what we have, and POST requests are in common use in this way. This use case also seems to fit in with one of the charter goals, to support "The ability to create a snapshot of a web page without the cooperation of its publisher." Hopefully this helps clarify the motivation and general structure of this proposal. (For anyone interested in more details, an initial rough proof-of-concept specification that we'd start from exists at: https://github.com/webrecorder/wacz-format) I suppose the next steps are to reach out to DISPATCH WG so we can take this conversation there! Thanks again, Ilya > > spt > > [0] Honestly, the proposal starts with you trying to get folks interested > in your idea and that=E2=80=99s how I interpret this email ;) > [1] https://datatracker.ietf.org/wg/dispatch/about/ > [2] > https://iipc.github.io/warc-specifications/specifications/warc-format/war= c-1.1/ > [3] https://www.iso.org/organization/9418.html > [4] > https://www.iana.org/assignments/media-types/media-types.xhtml#applicatio= n > > > > On Oct 5, 2021, at 15:18, Ilya Kreymer wrote: > > > > Hello, > > > > We would like to start the process of standardizing a format that fully > supports all the requirements for bundling web data, http request/respons= e > pairs, page lists, and associated metadata for web archiving use cases, a > 'web archive bundle' format. I wanted to inquire if the WPACK working gro= up > would be the right place for introducing such an effort, or if it would b= e > out of scope. > > > > Looking at the charter, there is definitely overlap with some, but not > all of the goals. In particular, the bullet points #1, 2, 3, 5 from > https://datatracker.ietf.org/doc/charter-ietf-wpack/ are shared goals of > the web archiving bundle format, while some of the other goals are less > important. > > > > The current CBOR-based bundle proposal is not sufficient to address the > full scope of web archiving requirements, and that's totally fine, as key > goals for that format are quite different. > > > > I am wondering if this group would be open to accepting a proposal for = a > different standard specifically geared towards addressing all of the web > archiving use cases, or if we should pursue other paths, such as other > working groups/new working group within IETF for such standardization > efforts. > > > > Here is a (very) brief summary of some of the requirements for web > archiving that will be fulfilled in this new format: > > - forwards and backwards compatibility with existing ISO WARC format, > which will be used to store the raw http request/response data. > > - an index based on URL + timestamp > > - index support for multiple request/response pairs of same URL, at sam= e > or different timestamp > > - support for storing request body, eg. for POST requests > > - random-access based URL+timestamp index that can be partially loaded > via random access. > > - support for different size web archive bundles, from a single page to > very large archive bundles consisting of many GBs of data or hundreds of > pages that are loaded entirely via random access. > > - support for text index to allow full-text search > > - support for combining multiple web archive bundles for a growing web > archive collection. > > > > We of course plan to elaborate on all of these but first want to > understand if this group would be the appropriate place for this work, or > not. > > > > Any advice/additional guidance on this would be appreciated, or any nex= t > steps to pursue this effort, if this is the right place for this work. > > > > Thank you, > > Ilya > > Webrecorder > > > > > > > > _______________________________________________ > > Wpack mailing list > > Wpack@ietf.org > > https://www.ietf.org/mailman/listinfo/wpack > > --0000000000004fca3705cdb2ad47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sean,

Thanks for th= e quick response! My responses below:

On Wed, Oct 6, 2021 at 8:55 AM S= ean Turner <sean@sn3= rd.com> wrote:
Illya,

With my chair hat on:

>From a purely procedural perspective, adopting work that is beyond what WPA= CK is chartered for would be considered out of scope. To do this new work, = WPACK we would need to recharter. Rechartering is not out of the question, = but getting that process kicked off involves some additional mechanics.

The process would likely start with a proposal to the DISPATCH WG [0][1]. D= ISPATCH is where new work in the ART area is evaluated. After discussing th= e work, DISPATCH can recommend a number of paths from suggesting that the n= ew work be added to an existing WG or suggesting that a new WG be formed to= address the work as well as rejecting the work entirely. The best bet to m= ake sure that discussion goes as smoothly as possible is to have an I-D rea= dy to go that people can read and comment on.

I hope that helps with respect to the process of getting new work adopted.<= br>

Thank you for clarifying that it would = be out of scope as chartered now (I wasn't quite sure as there are seve= ral overlapping goals) and the steps needed for moving forward.
= =C2=A0


With my chair hat off:

I do not have access to the WARC IS (ISO 28500:2017), but I found [2], and = that made me wonder about the following (I have no doubt these questions wo= uld also come up during dispatch discussions or maybe not because everybody= but me knows the answer):

- If there is already an ISO IS for the WARC format, then why is an RFC nee= ded? I am asking this primarily because the IETF and ISO (through ISOC) hav= e a Class A liaison [3]. Part of that agreement is that we will not produce= duplicative work.=C2=A0

- If there is already and ISO IS and it is a hard requirement maintain comp= atibility with the ISO WARC format, then what work is left to be done?

- What are the differences between ISO 28500:2017 and [2].

- Is there any reason ISO/IIPC has not already registered the application/w= arc and application/warc-fields media types with IANA. I could not find the= m in the list [4].

Apologies if th= e goals weren't made clear. The intent is not to modify WARC in any way= , but introduce a way of packaging WARC files to make them more usable.
The goal is to make web archives loadable (and creatable) via web br= owsers. The WARC format alone is not suitable for loading in the browser, d= ue to a lack of index and other metadata (pages, etc...). However, it conta= ins all of the http request and response data in a well-established format.=
There is a well established existing ecosystem of tools around W= ARC (https://gith= ub.com/iipc/awesome-web-archiving), and many PBs of data in WARC files.=

This idea boils down to the following: to bundle = WARC files, along with other data into a ZIP (or ZIP64) file. This allows f= or storing WARC files unaltered, plus adding a random-access index and othe= r requisite data to the ZIP file. The ZIP format (and ZIP64) are already ra= ndom access readable. While ZIP and WARC of course have their flaws, this s= imply combines two well-established formats to solve a number of problems r= elated to web archives in browsers.

Since this bun= dle format is a ZIP containing WARCs, the 'backwards compatibility with= WARC'=C2=A0 becomes as trivial as: unzip <web archive bundle> /p= ath/to/warc
and users get a standard WARC that is compatible with= existing ecosystem of tools.

The forwards compati= bility is that if/when a new ISO WARC format is introduced, it can also be = bundled in the same way. The WARC format itself is fully orthogonal to the = bundling of the WARC in the ZIP.

This propos= al would be about defining the contents and layout of the files inside the = bundled ZIP, one of which will be files of type WARC. Other formats will ne= ed to be more formally defined.

I wanted to offer = a very specific, but common example, relating to "2.1.3 Save and Share= a web page" that was adopted as part of=C2=A0draft-yasskin-wpack-use-= cases.
Suppose a user wants to save a web page that contains two = or more embedded YouTube videos. YouTube currently uses POST requests to th= e same URL, differing only
by request payload. To fully replay su= ch a page, it is necessary to save the request payload, and match the paylo= ad in the lookup when determining which video to load where.
Unfo= rtunately, the CBOR-based bundle specification will be unable to deal with = this use case, because request payloads are not saved. The web archive bund= le proposal will address this use case (and others) by storing the data as = WARC and specifying the necessary steps to include the POST data in the loo= kup index.

Of course, it'd be better if YouTub= e didn't do this, but we have to work with what we have, and POST reque= sts are in common use in this way.
This use case also seems to fi= t in with one of the charter goals, to support "The ability to create = a snapshot of a web page without the cooperation of its
publisher.&quo= t;

Hopefully this helps clarify the motivation and gener= al structure of this proposal.=C2=A0 (For anyone interested in more details= , an initial rough proof-of-concept specification that we'd start from = exists at: https://g= ithub.com/webrecorder/wacz-format)

I suppose t= he next steps are to reach out to DISPATCH WG so we can take this conversat= ion there!

Thanks again,
Ilya
<= div>

=C2=A0

spt

[0] Honestly, the proposal starts with you trying to get folks interested i= n your idea and that=E2=80=99s how I interpret this email ;)
[1] https://datatracker.ietf.org/wg/dispatch/about/
[2] https://iipc.gith= ub.io/warc-specifications/specifications/warc-format/warc-1.1/
[3] https://www.iso.org/organization/9418.html
[4] https://www.iana.org/a= ssignments/media-types/media-types.xhtml#application


> On Oct 5, 2021, at 15:18, Ilya Kreymer <ikreymer@gmail.com> wrote:
>
> Hello,
>
> We would like to start the process of standardizing a format that full= y supports all the requirements for bundling web data, http request/respons= e pairs, page lists, and associated metadata for web archiving use cases, a= 'web archive bundle' format. I wanted to inquire if the WPACK work= ing group would be the right place for introducing such an effort, or if it= would be out of scope.
>
> Looking at the charter, there is definitely overlap with some, but not= all of the goals. In particular, the bullet points #1, 2, 3, 5 from https://datatracker.ietf.org/doc/charter-ietf-wpack/ are shared goals of the web archiving bundle format, while some of the o= ther goals are less important.
>
> The current CBOR-based bundle proposal is not sufficient to address th= e full scope of web archiving requirements, and that's totally fine, as= key goals for that format are quite different.
>
> I am wondering if this group would be open to accepting a proposal for= a different standard specifically geared towards addressing all of the web= archiving use cases, or if we should pursue other paths, such as other wor= king groups/new working group within IETF for such standardization efforts.=
>
> Here is a (very) brief summary of some of the requirements for web arc= hiving that will be fulfilled in this new format:
> - forwards and backwards compatibility with existing ISO WARC format, = which will be used to store the raw http request/response data.
> - an index based on URL + timestamp
> - index support for multiple request/response pairs of same URL, at sa= me or different timestamp
> - support for storing request body, eg. for POST requests
> - random-access based URL+timestamp index that can be partially loaded= via random access.
> - support for different size web archive bundles, from a single page t= o very large archive bundles consisting of many GBs of data or hundreds of = pages that are loaded entirely via random access.
> - support for text index to allow full-text search
> - support for combining multiple web archive bundles for a growing web= archive collection.
>
> We of course plan to elaborate on all of these but first want to under= stand if this group would be the appropriate place for this work, or not. >
> Any advice/additional guidance on this would be appreciated, or any ne= xt steps to pursue this effort, if this is the right place for this work. >
> Thank you,
> Ilya
> Webrecorder
>
>
>
> _______________________________________________
> Wpack mailing list
> Wpack@ietf.org=
> https://www.ietf.org/mailman/listinfo/wpack

--0000000000004fca3705cdb2ad47-- From nobody Wed Oct 13 05:15:59 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 C21B63A08D6; Wed, 13 Oct 2021 05:15:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163412735571.12011.4541593062715967772@ietfa.amsl.com> Date: Wed, 13 Oct 2021 05:15:55 -0700 Archived-At: Subject: [Wpack] The WPACK WG has placed draft-yasskin-wpack-use-cases in state "Adopted by a WG" 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: Wed, 13 Oct 2021 12:15:56 -0000 The WPACK WG has placed draft-yasskin-wpack-use-cases in state Adopted by a WG (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-yasskin-wpack-use-cases/ From nobody Fri Oct 15 15:41:47 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 AD20E3A0E45; Fri, 15 Oct 2021 15:34:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: francesca.palombini@ericsson.com, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163433724169.17026.4694315301079730749@ietfa.amsl.com> Date: Fri, 15 Oct 2021 15:34:01 -0700 Archived-At: Subject: [Wpack] wpack - Requested session has been scheduled for IETF 112 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: Fri, 15 Oct 2021 22:34:13 -0000 Dear Sean Turner, 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) Wednesday, 10 November 2021, Session III 1600-1800 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/112/sessions/wpack.ics Request Information: --------------------------------------------------------- Working Group Name: Web Packaging Area Name: Applications and Real-Time Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 100 Conflicts to Avoid: People who must be present: tale Francesca Palombini Murray Kucherawy Sean Turner Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 25 09:37:17 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 DE6443A0C2F; Mon, 25 Oct 2021 09:37:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: wpack@ietf.org Message-ID: <163517983080.13909.6955862009250336940@ietfa.amsl.com> Date: Mon, 25 Oct 2021 09:37:10 -0700 Archived-At: Subject: [Wpack] I-D Action: draft-ietf-wpack-use-cases-00.txt 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: Mon, 25 Oct 2021 16:37:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Packaging WG of the IETF. Title : Use Cases and Requirements for Web Packages Authors : Jeffrey Yasskin Felipe Erias Filename : draft-ietf-wpack-use-cases-00.txt Pages : 23 Date : 2021-10-25 Abstract: This document lists use cases for signing and/or bundling collections of web pages, and extracts a set of requirements from them. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Packaging Working Group mailing list (wpack@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/wpack/. Source for this draft and an issue tracker can be found at https://github.com/wpack-wg/use-cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-wpack-use-cases/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-wpack-use-cases-00.html Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 12:52:15 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 D9C963A0DAB for ; Mon, 25 Oct 2021 12:52:12 -0700 (PDT) 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 hNhqlPBexk5e for ; Mon, 25 Oct 2021 12:52:08 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 1E2DF3A0DA6 for ; Mon, 25 Oct 2021 12:52:08 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id v17so11409426qtp.1 for ; Mon, 25 Oct 2021 12:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=hh/gM8j5va6uxaKXw51yQQxPFl3VgXjjs1pIQyemTYc=; b=DZl/CSguH6De1YQDAa04vKdYybj90Tfhk5jLpnDm1U2+Y7eYdG8urXk0CMgtkVzOCY 5G0nYDJMX5MkHFb1BzrxrYLAwjxV1ko70z4oBiFU+vud3WzHXexa7gh9tiLfbXYtCajj rYq5FiRZFtgPpboT274xE4tXiqzPnE+TIDGVI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=hh/gM8j5va6uxaKXw51yQQxPFl3VgXjjs1pIQyemTYc=; b=dv47ZJYjixmmYPE1FZwy+Jq0VuQEugNf4D9+Dap8sxFs65Bdnzvfbo2Y31u6Z0KNB7 N0MYd/tNFMg0TKgfF40RuYCS3N53m6bVGdIlV5IUo89X+fZ99Kl5SKp3D20Nk6PaxUxm cedCxasnq+erqRLSgjdjLuaBFtDIkNcmadHrPKm92Nk/q5kWcP8grputhx4GRGA7qey1 XTLQPbWNSktTcbU2ow/2ajeJ1FrpeDaoBXpR8n5WPBSsAIRzKgtCfYMUcv4oAPIS2m8P JbS/6e1AdJy0YW9A0CjEYp+tJGWq86q6RlIeIolGUcPnqJNuaGW/pOufCsLFREjk8wi9 Zbaw== X-Gm-Message-State: AOAM530ebxgbZdjvKBf9LYjYeaw3j3NCC9hTMZ8GBzYkB33sftfJmvNX bNqQNCtU79inVr7q4fxRzBjm9+zPSW3QDw== X-Google-Smtp-Source: ABdhPJwK/jcclO2gh/vVQbXY2u6aConbIzET5rmNsLXdjI3M+PfzU5bcBOtkOm4jAlhbeAJ8g5rMTQ== X-Received: by 2002:ac8:15a:: with SMTP id f26mr19800424qtg.317.1635191525994; Mon, 25 Oct 2021 12:52:05 -0700 (PDT) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id z186sm9093474qke.59.2021.10.25.12.52.05 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Oct 2021 12:52:05 -0700 (PDT) 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.120.0.1.13\)) Date: Mon, 25 Oct 2021 15:52:04 -0400 References: <163517983080.13909.6955862009250336940@ietfa.amsl.com> To: WPACK List In-Reply-To: <163517983080.13909.6955862009250336940@ietfa.amsl.com> Message-Id: <1F9D9374-9720-413D-B917-C22D5129D53F@sn3rd.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Wpack] I-D Action: draft-ietf-wpack-use-cases-00.txt 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, 25 Oct 2021 19:52:13 -0000 Jeffrey and Felipe -> thanks for getting this in under the deadline. WG -> This issue basically draft-yasskin-wpack-use-cases-02. Now it is = time to move the controversial use cases to an informative appendix. = Note that the WG repo is located here: https://github.com/wpack-wg/use-cases Cheers, spt > On Oct 25, 2021, at 12:37, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Packaging WG of the IETF. >=20 > Title : Use Cases and Requirements for Web Packages > Authors : Jeffrey Yasskin > Felipe Erias > Filename : draft-ietf-wpack-use-cases-00.txt > Pages : 23 > Date : 2021-10-25 >=20 > Abstract: > This document lists use cases for signing and/or bundling = collections > of web pages, and extracts a set of requirements from them. >=20 > Discussion Venues >=20 > This note is to be removed before publishing as an RFC. >=20 > Discussion of this document takes place on the Web Packaging Working > Group mailing list (wpack@ietf.org), which is archived at > https://mailarchive.ietf.org/arch/browse/wpack/. >=20 > Source for this draft and an issue tracker can be found at > https://github.com/wpack-wg/use-cases. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-wpack-use-cases/ >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-wpack-use-cases-00.html >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Oct 25 13:02:17 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 E04603A0DF8 for ; Mon, 25 Oct 2021 13:02:11 -0700 (PDT) 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 Lmb7axIFwSIJ for ; Mon, 25 Oct 2021 13:02:07 -0700 (PDT) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 4EE393A0BEF for ; Mon, 25 Oct 2021 13:02:00 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id n36-20020a17090a5aa700b0019fa884ab85so278329pji.5 for ; Mon, 25 Oct 2021 13:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=K7rkArJ0BFBJFfVMJ6zisjLEjByvnwFOkGlhVFEBUjM=; b=NNrtoEv3Ox6nL+QJOaCxgrn+f5+HkCjzgmnTGI+c/nN+yWk9LPZpQLQkWB9m5Rw75P 6OejAHfyaEthhfs7dLGMzh8OsG1xy4km+4yk3m6dAvoSZ85k2pbHbta11qvpgbocDHhU SksKQQhQXrPIUV9RrG9icumSuH+FnjZuqfX2ZSTubATQTtpNFRh0CV/Jntu8+8+TyHhX tbi7pvL82+fNTZ4eMdt4uYAIjXAJcT68BCPEOSHXU3Xj1daERhUElvGbSnfRnMdRSJtS 880f4N1iBlPcXZ3NAIti/YNs2liMCVgD5qwynwzTQ4EF5o4PjbrdgvXb2ezZ95vEheNd Y37Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=K7rkArJ0BFBJFfVMJ6zisjLEjByvnwFOkGlhVFEBUjM=; b=HD0MiSUjhQxbtOW3UUro2LwtKp4yj13S6SLpxxIwTI3bEIxBI6CflJlygsaZMD8FsY PA0nhKMgjX7v3GAG8uK+bLg2nzs+tu8Hdov/uyljxvizLmexVEV/HGLjO9dnvIYgUnSc 66TxgP7ADd9lIFeF0B839cikfcuh5DxM+6BNC7wmw2bS8meXQpCrh/0KMneBZe+LHilb zNV08+fMhAcrHMCScrznDQoFn5iSxsWMq1zWViN7EJjR2j+Bc+OB976dbdkb3+g77wM5 7WWsPokmmI54wnOwzKTZ7N8cpUAST7oTAZ01/wLyFspZ9ooZtFe0IOKJi7tKs6Unyfqg bHFg== X-Gm-Message-State: AOAM530htjOyZ0J5WHurciWwzWXpAqpN61RrIXMuJTpSbAhTn4JVR2gi dzo8FrwJNSk51smB5AEcy/P5ykcAS4M= X-Google-Smtp-Source: ABdhPJzkui5gpR+ZmR7US4m0goJLxqUoZHJePLlfiMtpzEjjAb/ikUlSr456F/WgiSOJtqBxnfFFAw== X-Received: by 2002:a17:90b:3b86:: with SMTP id pc6mr20659364pjb.143.1635192118608; Mon, 25 Oct 2021 13:01:58 -0700 (PDT) Received: from TVPC (c-73-158-116-21.hsd1.ca.comcast.net. [73.158.116.21]) by smtp.gmail.com with ESMTPSA id p16sm22884006pfh.97.2021.10.25.13.01.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Oct 2021 13:01:58 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Sean Turner'" , "'WPACK List'" References: <163517983080.13909.6955862009250336940@ietfa.amsl.com> <1F9D9374-9720-413D-B917-C22D5129D53F@sn3rd.com> In-Reply-To: <1F9D9374-9720-413D-B917-C22D5129D53F@sn3rd.com> Date: Mon, 25 Oct 2021 13:01:57 -0700 Message-ID: <002101d7c9db$2affd8b0$80ff8a10$@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: AQG/38F3t2ljq3R7XVyvDAOCotwWKQI7ZPZ1rAIZ7CA= Content-Language: en-us Archived-At: Subject: Re: [Wpack] I-D Action: draft-ietf-wpack-use-cases-00.txt 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, 25 Oct 2021 20:02:17 -0000 I thought the use cases weren't destined to be published as an RFC. So what is the point of moving "controversial" use cases? Even if it were published as an Informational RFC . I think my suggestions about MIME multipart were misunderstood. I wasn't suggesting you *use* MIME multipart. I was suggesting you *add* the use cases for MIME multipart as potential use cases for WPACK packaging -- For MHTML/related (which you cover), for form-data (which you don't), for alternative (which you might have), etc -- https://LarryMasinter.net https://interlisp.org > -----Original Message----- > From: Wpack On Behalf Of Sean Turner > Sent: Monday, October 25, 2021 12:52 PM > To: WPACK List > Subject: Re: [Wpack] I-D Action: draft-ietf-wpack-use-cases-00.txt > > Jeffrey and Felipe -> thanks for getting this in under the deadline. > > WG -> This issue basically draft-yasskin-wpack-use-cases-02. Now it is time to > move the controversial use cases to an informative appendix. Note that the > WG repo is located here: > https://github.com/wpack-wg/use-cases > > Cheers, > spt > > > On Oct 25, 2021, at 12:37, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Web Packaging WG of the IETF. > > > > Title : Use Cases and Requirements for Web Packages > > Authors : Jeffrey Yasskin > > Felipe Erias > > Filename : draft-ietf-wpack-use-cases-00.txt > > Pages : 23 > > Date : 2021-10-25 > > > > Abstract: > > This document lists use cases for signing and/or bundling collections > > of web pages, and extracts a set of requirements from them. > > > > Discussion Venues > > > > This note is to be removed before publishing as an RFC. > > > > Discussion of this document takes place on the Web Packaging Working > > Group mailing list (wpack@ietf.org), which is archived at > > https://mailarchive.ietf.org/arch/browse/wpack/. > > > > Source for this draft and an issue tracker can be found at > > https://github.com/wpack-wg/use-cases. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-wpack-use-cases/ > > > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-wpack-use-cases-00.html > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack From nobody Thu Oct 28 12:10:08 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 ED0393A0FDD for ; Thu, 28 Oct 2021 12:10:06 -0700 (PDT) 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 geL_cNqWZAu0 for ; Thu, 28 Oct 2021 12:10:02 -0700 (PDT) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 1014A3A0FC5 for ; Thu, 28 Oct 2021 12:10:01 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id k29so4751019qve.6 for ; Thu, 28 Oct 2021 12:10:01 -0700 (PDT) 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=8C5Zvgyo2dRao1x4vlxi4d1jKzkp2TTNtlOaQq5tAs8=; b=Bww6RNWN+oKIkI00GNRgYZ/mB6dkdGuL3Z71lsyE5xlo3m4pPKuqghTOz5jD2qVmYY scZzBA/f4+9o6kSiTLyHOeAPF3ufG1Xr35yAOlXWUHCRz9EDwheZc1kIwNHSbBTS6IWu Vqv0yH7nZZ4QW6q8Uukh310B0342caR1vgyEU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=8C5Zvgyo2dRao1x4vlxi4d1jKzkp2TTNtlOaQq5tAs8=; b=MgHRKjqLY+S/sUvUcAgcZ77iE/l8p55Ce71xLL0dPA6NMzCWAC5IvWRwUjI3bHZvts G2bl+na/WDxMt02gsAccw3ww1f35MdAP9TrRDwHtba/0YiOhDt1fZUe1KScW+h8J9dnB Q6DcpBshMKn7RgX2j3RTa29KyYbqKtF8umltRsRlnjdonkBWbtCX/L4eFqL41f+UHeng H9ULYe7GNv9EmAra3RH0HuResN7FXfMIKT6VB0SpuBXZfbLcYgjQdYt/uRDj1q7FkjHM ix+XuNKsZq61JtACK4UnwWoELuXqC/f/3IEQn3egn1KcrXhKm8zZHecF1Q7smaSlf9g0 9sIw== X-Gm-Message-State: AOAM531hDoM7fdeELjxh9KhyOjxQO+6WPv3PTa847qiWnH0VtQgQF4FZ L+02P606kwnB+7IRV/epbiI9t52jbCqhGQ== X-Google-Smtp-Source: ABdhPJx3ZzKQf8b6QSHBfj7x9I65WEXcSp3t5VkOHflXHl3bfN18AnmqQKeWOX6p+lu4szGYXE0hpw== X-Received: by 2002:a05:6214:226e:: with SMTP id gs14mr6058502qvb.4.1635448199642; Thu, 28 Oct 2021 12:09:59 -0700 (PDT) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id j20sm2678288qtj.72.2021.10.28.12.09.58 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Oct 2021 12:09:59 -0700 (PDT) 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.120.0.1.13\)) Message-Id: <8A626A49-410D-4F3E-8BB2-7F6A82B64E60@sn3rd.com> Date: Thu, 28 Oct 2021 15:09:57 -0400 To: WPACK List X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: [Wpack] wpack@ietf112 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: Thu, 28 Oct 2021 19:10:07 -0000 Hi! We have a meeting time scheduled for Wednesday, 10 November 2021 = from 1600-1800 (UTC). Please send in your agenda topics along with how = much time you think you will need to wpack-chairs@ietf.org. Cheers, Dave and Sean=