From nobody Fri Nov 1 09:58:08 2019 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 41CF1120B54 for ; Fri, 1 Nov 2019 09:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 uNKc35Ijz_L3 for ; Fri, 1 Nov 2019 09:57:51 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 BF296120B57 for ; Fri, 1 Nov 2019 09:57:50 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id g3so4800235ljl.11 for ; Fri, 01 Nov 2019 09:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=9lrVOrdFWi7Dz99FJIIaDGrtri63BxhZaTQItv+ilGs=; b=Rae0sihUsMZhQ0bWItKUsCfn1lmHkmogFm0hKdfzUAOtvIVKfaRtuDnXmXeyYyIvsV TIlfYHOEr+dfUV+qg5+8jtQZ1zFIBoTP4iKlQ20JeGCR5VWC3ABh0Sw725kHuUylTcwn wHc8NGY3YGPFqKqYV/y9Uau6/f9BrbHwx7Pt6NA0p0/TWWFATPkyp8evCACtEU5giKU5 J0OLxBoc9phDOKOOaFkPCA7Eq53vh38nJXPA/9wNkch+UyuGmR1s/SuUr7yJjk1KKHLm sLglbEBNwFGfGef0/smx/+COpFJGJh5ih2QK/xeNMh1G6W7Z7Wo+n1SjHmb1Eb/tjt9C WkIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9lrVOrdFWi7Dz99FJIIaDGrtri63BxhZaTQItv+ilGs=; b=UnQXyoUx1TLqA3mkP8CcWwuZLtsGbbd3TubTv5KWEyBk1OyYvRR33JukJCKJVFoXu2 YVzsxDh7ssvJVRMbeBifO2o0piS8frx83SIu4gde2IwpBr6c4OrVL6DKt85lYeVr5UnQ /gaaAlR5jzmj7pYDjtVc1Yyp86bEW3QNZ20bsVUuVWOiK7Eqzd5aq84csHLjSN1IKyEA TFbCfBHp+3H2fTNDrk+3PrJnpP1KsOLDnCFbvRYHKsVIYry+KmEz7akJmdJiluKD9s6P B7BOgvirLwiAPa24vbEgD6VESbwRUtMagE46YByrCwaewc34s6qbqb8ZMgthIU1hqgD2 elPA== X-Gm-Message-State: APjAAAU2EPlyIuj6whVqeXGYqKyEyRp3YIAJf6MnJVJpwKev8GJgVz0b oL6eNNC48tAAAdDEybmGxAyPfNB1itGR4mwVOKMHfzp8X2M= X-Google-Smtp-Source: APXvYqyvhLNwpKl147KdXKy7oIwuBzuQNhr/qYjMCpkUmrmARJ+hnImdB8MY31EM4bOf3eG/At+6qmI9Xq4ZGvLYgFU= X-Received: by 2002:a2e:3e18:: with SMTP id l24mr9080002lja.48.1572627468854; Fri, 01 Nov 2019 09:57:48 -0700 (PDT) MIME-Version: 1.0 From: Eric Rescorla Date: Fri, 1 Nov 2019 09:57:12 -0700 Message-ID: To: lake@ietf.org, IESG , wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000a5325905964bdd40" Archived-At: Subject: [Wpack] LAKE/WPACK conflict 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, 01 Nov 2019 16:58:02 -0000 --000000000000a5325905964bdd40 Content-Type: text/plain; charset="UTF-8" Hi IESG folks, I regret missing this earlier, but the conflict between LAKE and WPACK is really bad. I can think of a whole pile of people who are potentially implicated in both (myself, Sean Turner, Richard Barnes, Martin Thomson, ...). It would be really great if we could move one of these. I know it's always really hard to make the schedule work and individual suggestions always seem to miss the big picture, but what about swapping LAKE with SUIT? ISTM that there's a lot less overlap there. -Ekr --000000000000a5325905964bdd40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi IESG folks,

I regret missing this earlier, but t= he conflict between LAKE and WPACK
is really bad. I can think of a whole= pile of people who are
potentially implicated in both (myself, Sean Tur= ner, Richard Barnes,
Martin Thomson, ...). It would be really great if w= e could move
one of these.

I know it's always really hard to = make the schedule work and individual
suggestions always seem to miss th= e big picture, but what about
swapping LAKE with SUIT? ISTM that there&#= 39;s a lot less overlap there.

-Ekr

--000000000000a5325905964bdd40-- From nobody Fri Nov 1 10:05:30 2019 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 11C46120AEE for ; Fri, 1 Nov 2019 10:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 FhwpFThXaxb8 for ; Fri, 1 Nov 2019 10:05:26 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 6B56B120A3E for ; Fri, 1 Nov 2019 10:05:26 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id t5so10970715ljk.0 for ; Fri, 01 Nov 2019 10:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=13Kcz53PwghyEozlwr4saxOKf2chLHQ4RpAFUl4sTGY=; b=cW5XgNCJnkU5wDnoP+OA43F/Y3Ipfgn3nyQyqAvRL1gcg70Y1eqkfFbSffY5GOARZK EQ/nIsXu1xHSPoXa1pluJ5jAiWMZkgA38pzFpLCxyESEDkKBHhLxCE+Co5e0NlTQLDnP +R/ih3lglqWr/NWeY/p3lYapqELc5/asALxz8lMBEguleQpE4EauFFooQM5rEit5BSpG Y1vN5FbuKjQ0Y/2Ca5mDEH3scszVMutxxAAF9baWwuD2lQm/JZThlv8TOWlGCAFWr/8U t7WVBq+rLIa4djNVr4BRXGc2uNZVLCLMVAQt7kxVue2TmDAfDKv+dyrUSpBtmJQFYQJF LGpA== 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; bh=13Kcz53PwghyEozlwr4saxOKf2chLHQ4RpAFUl4sTGY=; b=DZS/Aqrrvxi9unxftKna9v3lZ2o7LO8I9MWthMRDJ8MKNUDgJrwfWnnoTZs4zYTpFs jZo0rGfrE1+6qSY6+8nGM2fa8TxpTl6PjO6zovuWosiIXHnQ37Lqw3rGxv6ayuDd6i96 xsYLxzgi28fs/IHimmb3S4UglZQnfNVToVprKD5An5qP6zN2C2yKNICH3Qu6WnB0jQHt tTpmgEW8q+QAiK7i5tIk5UPOSJbAeilsIEm/IkDgYR5aSSsPcZXkhTBiMhnOl54t4xWq wjkNGZwLQAZEDE0CJh3xzKBQhCTmh3yMGa7x4x49gc99LMdpf7etrMoLVsJrUZpSnv/+ hSKQ== X-Gm-Message-State: APjAAAUZW1LbgtRjaRDKeoEoeERo9I2AkmlYdlU4OVK/Wnh9nMqU7Eux MdmclRjHYje3u5B+XLSJdAwNO4Hy50U326s6CtOqCg== X-Google-Smtp-Source: APXvYqxfQbtZ+163WunCgz9LllsaKEZWdHYvWzpEeSG0eXwnlQSLxEATKhc29V/wslA64jLLKA4Jo22x8sG490ReSPk= X-Received: by 2002:a05:651c:10c:: with SMTP id a12mr8922590ljb.93.1572627924606; Fri, 01 Nov 2019 10:05:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 1 Nov 2019 10:04:46 -0700 Message-ID: To: lake@ietf.org, IESG , wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000cf6b9c05964bf81a" Archived-At: Subject: Re: [Wpack] LAKE/WPACK conflict 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, 01 Nov 2019 17:05:28 -0000 --000000000000cf6b9c05964bf81a Content-Type: text/plain; charset="UTF-8" And proving my point about me missing the big picture, BenK points out to me that SUIT and ABCD conflict.... I'll refrain from making other suggestions until I know whether other people are concerned about this. -Ekr On Fri, Nov 1, 2019 at 9:57 AM Eric Rescorla wrote: > Hi IESG folks, > > I regret missing this earlier, but the conflict between LAKE and WPACK > is really bad. I can think of a whole pile of people who are > potentially implicated in both (myself, Sean Turner, Richard Barnes, > Martin Thomson, ...). It would be really great if we could move > one of these. > > I know it's always really hard to make the schedule work and individual > suggestions always seem to miss the big picture, but what about > swapping LAKE with SUIT? ISTM that there's a lot less overlap there. > > -Ekr > > --000000000000cf6b9c05964bf81a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And proving my point about me missing the big picture= , BenK points out to me that SUIT and ABCD conflict....

I'll refrain from making other suggestions until I know whether o= ther people are concerned about this.

-Ekr


On Fri, Nov 1, 2019 at 9:57 AM Eric Rescorla <ekr@rtfm.com> wrote:
Hi IESG folks,
I regret missing this earlier, but the conflict between LAKE and WPACK
= is really bad. I can think of a whole pile of people who are
potentially= implicated in both (myself, Sean Turner, Richard Barnes,
Martin Thomson= , ...). It would be really great if we could move
one of these.

I= know it's always really hard to make the schedule work and individual<= br>suggestions always seem to miss the big picture, but what about
swapp= ing LAKE with SUIT? ISTM that there's a lot less overlap there.

= -Ekr

--000000000000cf6b9c05964bf81a-- From nobody Fri Nov 1 10:07:54 2019 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 642CD120BD9; Fri, 1 Nov 2019 10:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=heapingbits.net header.b=RrCHVqIU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OUW/pRkd 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 G71fHiHDMXA8; Fri, 1 Nov 2019 10:07:43 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D766120BC4; Fri, 1 Nov 2019 10:07:39 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id B0C8A533; Fri, 1 Nov 2019 13:07:37 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Fri, 01 Nov 2019 13:07:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=eR1AVn9JszKyiZ0BWZvBw+Eqeq3R 41aw0dkS+dLu7L8=; b=RrCHVqIUOT6aodDh8a4H+qh2VqbPfUqv3+KKBimksmVJ AhGOBNhRIWShgnOAa3Pp3jmGQ1Ud5sk8/+T5AFjzRyuExwi6UszSS6L65uh9ZJR0 2cIk3aceozkdfcHtb1etxGWr+ctxO2r/R3FpcHTmP+pF8Gt/9r3ds7UQJDJevgqM t18SybL5rInY9yDAmd7xxr+uIvd2/mx2+K41aeLHvJz+YrOLiNhiXlFxx6kvbSda W1QDitCBXXOZk1g7Q2e2UzGUaCjk/YjO+ev4sjmpgG6Zh+FSMEc32xrIOvMxPVJd C41Q8r3CnI7G4gujKRc8gQ+e9L/1YOi1b7S36N3M+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=eR1AVn 9JszKyiZ0BWZvBw+Eqeq3R41aw0dkS+dLu7L8=; b=OUW/pRkdl2NVBwkUCriasn a1XTzxKijFv/x/qM2SnbMUmdfZKmu8WyymJkFrLQUr/i3A+8HLJM28zAJOOWn71Y Uk3kjBT+QlC4T7PFoUmjn0W9/nLn6W+LxcW0nEy71cTDqQ4Cn4QuOQN0E9fMNT8z Mls2U3K2PONMcAragBL2w3wBH4tetWl7EXlc7b6OUyWGQxXne+4JuCa9umLiwSva 8NGAahJ/LLSDOGEzCBHywEYLgF1xF8bD4ob5GsHSot2ZwSKBi4aORYvw6yxBVlLS JuTW1EZzLir0Yg84xMlJjmWSSFwIRAbKVZ1xAQ/FguNieMlROBuV2PNXh2kvqErw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtjedgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D1EC93C00A1; Fri, 1 Nov 2019 13:07:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 01 Nov 2019 10:07:15 -0700 From: "Christopher Wood" To: "Eric Rescorla" Cc: lake@ietf.org, IESG , wpack@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] [Lake] LAKE/WPACK conflict 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, 01 Nov 2019 17:07:46 -0000 FWIW, this conflict causes problems for me, too. On Fri, Nov 1, 2019, at 10:04 AM, Eric Rescorla wrote: > And proving my point about me missing the big picture, BenK points out > to me that SUIT and ABCD conflict.... > > I'll refrain from making other suggestions until I know whether other > people are concerned about this. > > -Ekr > > > On Fri, Nov 1, 2019 at 9:57 AM Eric Rescorla wrote: > > Hi IESG folks, > > > > I regret missing this earlier, but the conflict between LAKE and WPACK > > is really bad. I can think of a whole pile of people who are > > potentially implicated in both (myself, Sean Turner, Richard Barnes, > > Martin Thomson, ...). It would be really great if we could move > > one of these. > > > > I know it's always really hard to make the schedule work and individual > > suggestions always seem to miss the big picture, but what about > > swapping LAKE with SUIT? ISTM that there's a lot less overlap there. > > > > -Ekr > > > -- > Lake mailing list > Lake@ietf.org > https://www.ietf.org/mailman/listinfo/lake > From nobody Fri Nov 1 10:12:12 2019 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 18BCB120C27; Fri, 1 Nov 2019 10:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 vYQqRU8yKpJn; Fri, 1 Nov 2019 10:12:08 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B03F120C0A; Fri, 1 Nov 2019 10:12:08 -0700 (PDT) Received: from [192.168.217.102] (p548DCA87.dip0.t-ipconnect.de [84.141.202.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 474TJQ3xVTz10Xp; Fri, 1 Nov 2019 18:12:06 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Fri, 1 Nov 2019 18:12:06 +0100 Cc: lake@ietf.org, IESG , wpack@ietf.org X-Mao-Original-Outgoing-Id: 594321124.425259-c5a17d5d0542ee3be5b387783dde67a7 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Wpack] LAKE/WPACK conflict 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, 01 Nov 2019 17:12:11 -0000 On Nov 1, 2019, at 18:04, Eric Rescorla wrote: >=20 > I=E2=80=99ll refrain from making other suggestions until I know = whether other people are concerned about this. In = =E2=81=A8=E2=81=A9, I surmised I might be the only one who cares. Maybe = not. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Nov 1 10:28:31 2019 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 B9C9E120C2D; Fri, 1 Nov 2019 10:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 x9bSIDLZpjwj; Fri, 1 Nov 2019 10:28:28 -0700 (PDT) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (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 63C25120C7D; Fri, 1 Nov 2019 10:28:28 -0700 (PDT) Received: by mail-io1-f44.google.com with SMTP id 18so11688999ion.6; Fri, 01 Nov 2019 10:28:28 -0700 (PDT) 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=P6Ajwk8EpjMmwUX/A2X0yxDQTzAxkEnYD9runROAzhA=; b=W6O8gMK0qdFvqlQ1f5Oie4zTfzRMoTcWO4UnVcT4BJy1Mf1lYDstK7P9USqlcWwBO1 0DhGvYU77Xmk+MtjHeiPSKnWoRnQ48nBLcy/aNIlhP6UEAJ0h6RR3OKkaPBbz92Y/NbI 3oSDvk73u52Be1Jk9io828bJfyLUStKAiBBjbk7g+5dwNpjm1objWavnUEwpyuAo61bm CRU7FmPkxcv9oCseJkApUXF04fwMxgElgWrDadn2tZuQvwoXsZaSZKviDKCZXcT//GE0 10f59y9C1saUllY1ICv5yhGAgOoQ/TPXC+snZMKWFEAp9W8PDT6+NADnUPk+UJKViFZR Ni4Q== X-Gm-Message-State: APjAAAX+ZjFU7O1mpiJfvULjC4kw4LYdZB/PFqpoYR0r8HpPXr+76h3P S6F8CnMygGbQdYtNbzOgoKXusEcMFYS1thCM76Y= X-Google-Smtp-Source: APXvYqyakGX9mtxwpaLUqVmGdQpa1d5WhSPQqMgZLCXoPiHIndyQZienDB5LWrRx+lQHyVfE2PIDwUxDFCBurMKyODI= X-Received: by 2002:a6b:c8cd:: with SMTP id y196mr11681611iof.266.1572629307337; Fri, 01 Nov 2019 10:28:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Fri, 1 Nov 2019 13:28:16 -0400 Message-ID: To: Eric Rescorla Cc: lake@ietf.org, IESG , wpack@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Wpack] LAKE/WPACK conflict 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, 01 Nov 2019 17:28:30 -0000 We will see what we can do. Barry On Fri, Nov 1, 2019 at 12:58 PM Eric Rescorla wrote: > > Hi IESG folks, > > I regret missing this earlier, but the conflict between LAKE and WPACK > is really bad. I can think of a whole pile of people who are > potentially implicated in both (myself, Sean Turner, Richard Barnes, > Martin Thomson, ...). It would be really great if we could move > one of these. > > I know it's always really hard to make the schedule work and individual > suggestions always seem to miss the big picture, but what about > swapping LAKE with SUIT? ISTM that there's a lot less overlap there. > > -Ekr > From nobody Fri Nov 1 10:34:57 2019 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 3E553120CC5 for ; Fri, 1 Nov 2019 10:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=ipv-sx.20150623.gappssmtp.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 iMGP9jUfMhnt for ; Fri, 1 Nov 2019 10:34:48 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 8C437120CBC for ; Fri, 1 Nov 2019 10:34:48 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id v186so8822755oie.5 for ; Fri, 01 Nov 2019 10:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2raIQOKdw/+U5RSZfS2WpVVwpHYywo35MjaBGUlp28k=; b=GZRwtP0Cs3p77z+D+31OFrWSR47vutgupp8Qj9gE39sPJrDGKl0cOmeoeKEeQZI2s7 glBwrV9Fq5ciewEJocqR61FBEW0ZZ4OFjpQrKdIiKpxvNHnqhZB4DN6u6OH2Zxc8E4wu bS2iw6S7x9pd95P49xfSRPrEIptu/Vge4gk79dsLPTZ9EmjRsAhRScx/RPNFzVNrkXwH N5jutUFKS0IKy80mnX2FIImTl1mx2fba49vZHpWF1jiexBLJ+zmJKsyUD21LoYWDoVJ4 uUu2pT8xGSr0xCMdaPGaSkwMD/4LISPz8uMwusWt7KmOfalRLDy2ar6yN9J886rJ2SWO +1Cw== 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=2raIQOKdw/+U5RSZfS2WpVVwpHYywo35MjaBGUlp28k=; b=bppxf6Guj4R5dNs9/TCTbTcpOgpaJYopNzMjLg/DZHal87Mj3PXB17uHbaTXjUpyt2 Hy+A2IQWUox+bgNcOWYJqh7rHaXb1q/PnmVrKIeMv+Dj/5nabLxF1OkBTRrKJO2N1Bjx EcbXRI8QFXz+VU0GfvzhGKmhNWJXbSmblMPiUVc24E4gDZ7TdD5hMo49Wcym+jgpGzA7 Xxq0C6tzUazLx0Kj78VgtvJd+yrQecvHN+h+k4vDMvO9czpX2FpwQ531gTkfVBwrJ6FT NtOnkSXEtcFpvwIuEcegDNcZh9yFpZlc9um4HB6XVvavUBISkdDyOZ1vxX3eNwtc0LoO wxXw== X-Gm-Message-State: APjAAAXagSZanmw9/Ur7u3SLHUdkAzzVND6enWnTWS4mYaykB2zqG5re oIdIrCFcLnzlyOfKpiSeueX3lzlIXElm6DG0OS/K5g== X-Google-Smtp-Source: APXvYqw6ueoqTKbj/eouS9yLozS9EOm2znI4IZnRrXHSfyZsnECpTJdP2dMqluW4FuTNzxfYKitSmXliAR1zNyWwNZY= X-Received: by 2002:aca:d807:: with SMTP id p7mr2306020oig.149.1572629687606; Fri, 01 Nov 2019 10:34:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Fri, 1 Nov 2019 13:34:22 -0400 Message-ID: To: Carsten Bormann Cc: Eric Rescorla , lake@ietf.org, wpack@ietf.org, IESG Content-Type: multipart/alternative; boundary="000000000000e4b6b905964c6173" Archived-At: Subject: Re: [Wpack] [Lake] LAKE/WPACK conflict 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, 01 Nov 2019 17:34:54 -0000 --000000000000e4b6b905964c6173 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This conflict is problematic for me as well. On Fri, Nov 1, 2019 at 1:12 PM Carsten Bormann wrote: > On Nov 1, 2019, at 18:04, Eric Rescorla wrote: > > > > I=E2=80=99ll refrain from making other suggestions until I know whether= other > people are concerned about this. > > In =E2=81=A8< > https://mailarchive.ietf.org/arch/msg/lake/ZK2n8srX578-qIZOKOXVThayNL8>= =E2=81=A9, > I surmised I might be the only one who cares. Maybe not. > > Gr=C3=BC=C3=9Fe, Carsten > > -- > Lake mailing list > Lake@ietf.org > https://www.ietf.org/mailman/listinfo/lake > --000000000000e4b6b905964c6173 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This conflict is problematic for me as well.

=
On Fri, No= v 1, 2019 at 1:12 PM Carsten Bormann <ca= bo@tzi.org> wrote:
On Nov 1, 2019, at 18:04, Eric Rescorla <ekr@rtfm.com> wrote:
>
> I=E2=80=99ll refrain from making other suggestions until I know whethe= r other people are concerned about this.

In =E2=81=A8<https://mailar= chive.ietf.org/arch/msg/lake/ZK2n8srX578-qIZOKOXVThayNL8>=E2=81=A9, = I surmised I might be the only one who cares.=C2=A0 Maybe not.

Gr=C3=BC=C3=9Fe, Carsten

--
Lake mailing list
Lake@ietf.org
https://www.ietf.org/mailman/listinfo/lake
--000000000000e4b6b905964c6173-- From nobody Wed Nov 6 12:11:57 2019 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 B583B120058 for ; Wed, 6 Nov 2019 12:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 el5x0B8Qlv1C for ; Wed, 6 Nov 2019 12:11:54 -0800 (PST) Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) (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 1D3FB12004A for ; Wed, 6 Nov 2019 12:11:54 -0800 (PST) Received: by mail-ot1-f48.google.com with SMTP id b16so21962356otk.9 for ; Wed, 06 Nov 2019 12:11:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tS0ha43RKeb522csbSwTxbnCM8vs/Ko27/inccDo0wA=; b=CK84E2+O0AVk+mJsDFMpWjSKNUemdG8JiTKd+R2ixbFD5CIZSRzwjfMfDjBOXJWDwc ZceXDL1HwzcLiJLBT8hShRSeNdnQ+LT0KK+6i0ywVHHNhiynz7m6bSgSflPtS07P1H28 QoHZc93l72j/DPj2ztBuU2DStOWVrH4q8B4tNOyuvzlp4npI6OPhTDPxHZA0bfExE05o AuPcF+5lPsipNb+fqp3eVQ9ntUfvzt7eq1WniBmg42cbzj8KsjnE8AM8ok1Yj6Kp2g3k 0y/W7sUTI1Rb+CriP4VMdp+s0S46+ysqDS7aGku9RGkfalm42+HSQUuai7xeUYLK/Bbs c3Yg== X-Gm-Message-State: APjAAAUgYIK1qqAN7jEKtiDwlfpzeu6gMc2QxJMVcx4iEhmzNsE+4YME r3AgnTWgamSyXWwrVKscOrl56QmTW5cuF7a4vOyk2wdf X-Google-Smtp-Source: APXvYqy2HKGhTSg1pqvQtvQQ1RlYeOuCyLpJR9c4cXC6PONXsY5sgDoakXpySAc/feHfyUDRiAm16l3T9HbLShtIu4g= X-Received: by 2002:a9d:6b90:: with SMTP id b16mr1263257otq.37.1573071112912; Wed, 06 Nov 2019 12:11:52 -0800 (PST) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Wed, 6 Nov 2019 15:11:42 -0500 Message-ID: To: wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000e443dc0596b32884" Archived-At: Subject: [Wpack] DARE Envelope and Sequence 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 Nov 2019 20:11:56 -0000 --000000000000e443dc0596b32884 Content-Type: text/plain; charset="UTF-8" It seems to me that there are two possible ways forward for WPACK The first is to reuse ZIP, the second is to do a completely new packaging format. It is not clear which people prefer. If you are going to be going down the 'new format' route, I would ask that the DARE format be considered. This will be discussed in part in the MATHMESH BOF on the Monday: http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html DARE and DARE Sequence were designed to address a different set of requirements. The idea of DARE Envelope is to provide a JSON/JOSE equivalent to PCKS#7 with the necessary hooks to support DARE Sequence which is an append only log file format with incremental encryption and authentication capabilities (i.e. it supports Blockchain type capabilities if you want to use that name). The chief concern in the design of DARE Sequence is to support encrypted persistence stores. But it was tested as an archive format as a design check. I understand that some believe WPACK scope should be narrower, but the DARE solution is not complex and I find it very difficult to believe that encryption won't end up being added to any new format as an extension. So I think it better to accept that from the start. We should at any rate discuss the possibility of a common approach. I can't drop my requirement for encryption because the whole point of the Mesh is to be able to use threshold cryptography to provide true end to end encryption of stored data. So one use of a DARE sequence might be to record encrypted comments on an encrypted Web page that neither the Web Server nor the key service nor any other cloud service has the ability to decrypt. For those of you who prefer a video presentation, the DARE format is described here https://www.youtube.com/watch?v=mLsEhzBpfNA&list=PLK2hHAOxepEgGUx4SitfD4pIPHi86KHpi&index=9&t=2s https://www.youtube.com/watch?v=T5fRneFOueM&list=PLK2hHAOxepEjcU9yXCqV39B0VB-gB7Abj&index=11&t=2s The DARE archive format is described here (available Friday) https://www.youtube.com/watch?v=9ZDUa6wvDkY&list=PLK2hHAOxepEjcU9yXCqV39B0VB-gB7Abj&index=8&t=4s --000000000000e443dc0596b32884 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It = seems to me that there are two possible ways forward for WPACK

The first is to reuse ZIP, the second= is to do a completely new packaging format. It is not clear which people p= refer. If you are going to be going down the 'new format' route, I = would ask that the DARE format be considered. This will be discussed in par= t in the MATHMESH BOF on the Monday:

http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html<= /a>=C2=A0
=C2= =A0
DARE an= d DARE Sequence were designed to address a different set of requirements. T= he idea of DARE Envelope is to provide a JSON/JOSE equivalent to PCKS#7 wit= h the necessary hooks to support DARE Sequence which is an append only log = file format with incremental encryption and authentication capabilities (i.= e. it supports Blockchain type capabilities if you want to use that name).<= /div>

The chief concern in the = design of DARE Sequence is to support encrypted persistence stores. But it = was tested as an archive format as a design check.=C2=A0

I understand that some believe WPACK scope = should be narrower, but the DARE solution is not complex and I find it very= difficult to believe that encryption won't end up being added to any n= ew format as an extension. So I think it better to accept that from the sta= rt.=C2=A0

<= /div>
We should at an= y rate discuss the possibility of a common approach. I can't drop my re= quirement for encryption because the whole point of the Mesh is to be able = to use threshold cryptography to provide true end to end encryption of stor= ed data. So one use of a DARE sequence might be to record encrypted comment= s on an encrypted Web page that neither the Web Server nor the key service = nor any other cloud service has the ability to decrypt.


For those of you who prefer a video presentation, the = DARE format is described here
https:= //www.youtube.com/watch?v=3DmLsEhzBpfNA&list=3DPLK2hHAOxepEgGUx4SitfD4p= IPHi86KHpi&index=3D9&t=3D2s=C2=A0=C2=A0
https://www.youtube.com/watch?v=3DT5fRneFOueM&list= =3DPLK2hHAOxepEjcU9yXCqV39B0VB-gB7Abj&index=3D11&t=3D2s=C2=A0= =C2=A0

=
The DARE archi= ve format is described here (available Friday)
https://www.youtube.com/watch?v=3D9ZDUa6wvDkY&list=3DPLK2hH= AOxepEjcU9yXCqV39B0VB-gB7Abj&index=3D8&t=3D4s=C2=A0=C2=A0
--000000000000e443dc0596b32884-- From nobody Thu Nov 7 12:44:37 2019 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 6A84F120975; Thu, 7 Nov 2019 12:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=no autolearn_force=no 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 cgf8JItfUOkU; Thu, 7 Nov 2019 12:44:28 -0800 (PST) Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) (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 D0CD912095E; Thu, 7 Nov 2019 12:44:27 -0800 (PST) Received: by mail-ot1-f46.google.com with SMTP id z6so3256205otb.2; Thu, 07 Nov 2019 12:44:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Eld5JYuRxwrEWp6DFQ0j6hEMJp8QtGoie15pRJ2KaqI=; b=cVCa4SkvATpJnf1qHUon3dXhsjEox0nh22rGWCcApfwznOnSHDhMd3eNT6IernTYdI IMWGa0pAtVWqqT1HKpNnW+3N4fSyld4wT7sJZe5RILT5z9r1Sp+pl6TXxB5hMHzgaxmB +V5I5FeT5Eal0acG6PUtMi/U+g6/8Crt9qBRX5lhevHARt7gWnXDefIe64HNQoopBm7A XuqAyUFsdc36AzDvVAlyzxkBUiSDLu9nq6Ium83Wto1Vza/Gm/DrpS8YPZYkVRPeiq0D wPV8/bYjqUBVBd6i9XPHD+Vuxk8ffcXV2IBW8zImXkh2OVKp+Mlo0/ONpEOS1EGUVfBx AeUA== X-Gm-Message-State: APjAAAVGM+4biQ0VK4Ad8tfr7NMcAEzjcWRLNakKWR13eSgkyjADU9FZ 6V8z420o9rtblSYXBvIGYahIvetxAAE0bewamhPlhxRv X-Google-Smtp-Source: APXvYqyNOsBQAI5EpYIxlpzWRz/NIubVVlhNfNqYoDkCOwK4PG7JdoBRmWxJh6/e+UGFTJcnHrw3FaxUJGzBeodijYw= X-Received: by 2002:a9d:6b90:: with SMTP id b16mr4865310otq.37.1573159466664; Thu, 07 Nov 2019 12:44:26 -0800 (PST) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Thu, 7 Nov 2019 15:44:16 -0500 Message-ID: To: wpack@ietf.org, mathmesh@ietf.org Content-Type: multipart/alternative; boundary="0000000000002f86870596c7bbe1" Archived-At: Subject: [Wpack] Interaction between MATHMESH and WPACK 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, 07 Nov 2019 20:44:29 -0000 --0000000000002f86870596c7bbe1 Content-Type: text/plain; charset="UTF-8" Given that we have two BOFs that are considering similar technology proposals, it seems to me that we should consider whether we need to have two new formats or whether one can do both. To that end, I would like to encourage some discussion of these issues prior to Singapore. In particular, I would like to see if a common approach is feasible. Otherwise, the risk is we end up having to support two new formats. Looking at the various WPACK proposals, I can see two possible paths. One is to work out some way to cram what is wanted into ZIP or MHTML. The objective being 'code reuse'. Which is great in theory but only if it is possible to reuse the existing code. Re-use of existing design is considerably less appealing and especially so if we end up needing to do backwards compatibility etc. This also applies to the attempt to reuse parts of HTML. I stopped being active in HTML when we were still trying to move from 1.0 to 1.1. It was already clear that RFC822 header syntax was a major constraint but it was too late to change that decision without a complete redesign. Which we couldn't even get to in HTTP/2 and are only just starting to look at for HTTP/3. WPACK should attempt to hit the target where it is going to be in the future, not where it is now. Some of us have been through signing headers in the world of DKIM. It was necessary but it certainly wasn't at all pleasant. So what I would like to see WPACK do for its own sake even if it is never taken up in the world of HTTP, is to introduce the structured separation of headers into functional units that we wanted in HTTP/1.1 (Simon Spero tried) but couldn't do. In other words instead of Connection: Keep-Alive Content-Type: text/html Date: blah Content-Encoding: gzip We should have had (using JSON for clarity but at the time it was S-expressions being discussed) Connection: Keep-Alive Date: blah Content-Meta { "type":"text/html" "Content-Encoding" : "gzip" } If we had had this type of separation, HTTP/1.1 would have been a lot easier. The protocol headers can and do change in transit. But if the content metadata had been collected together in one place it should actually be unmolested end-to-end unless the content itself had been changed. It does present the material in a form that allows it to be signed. I don't think the choice of JSON or CBOR is particularly consequential. But the browser is going to have a JSON parser which is why I focus on that. Providing a ZIP like capability does not require us to go any further than content metadata. But WPACK potentially requires a bit more as we are not just looking to display the content to the user, we want to push it into their browser cache. And so it is not just the content and associated metadata that are at issue here, it is also the binding of that data to the resource identifier. So what we are looking at is actually something more like: Resource { "uri" : "http://example.com/fred.html" "expires" : "2019-dec-01: blah" "Content-Meta" : { "type":"text/html" "Content-Encoding" : "gzip" } And this could potentially be signed separately in certain contexts. --0000000000002f86870596c7bbe1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Giv= en that we have two BOFs that are considering similar technology proposals,= it seems to me that we should consider whether we need to have two new for= mats or whether one can do both.

To that end, I would like to encourage some discussion of these iss= ues prior to Singapore. In particular, I would like to see if a common appr= oach is feasible. Otherwise, the risk is we end up having to support two=C2= =A0new formats.

Looking a= t the various WPACK proposals, I can see two possible paths. One is to work= out some way to cram what is wanted into ZIP or MHTML. The objective being= 'code reuse'. Which is great in theory but only if it is possible = to reuse the existing code. Re-use of existing design is considerably less = appealing and especially so if we end up needing to do backwards compatibil= ity=C2=A0etc.
<= br>
This also a= pplies to the attempt to reuse parts of HTML. I stopped being active in HTM= L when we were still trying to move from 1.0 to 1.1. It was already clear= =C2=A0that RFC822 header syntax was a major constraint but it was too late = to change that decision without a complete redesign. Which we couldn't = even get to in HTTP/2 and are only just starting to look at for HTTP/3. WPA= CK should attempt to hit the target where it is going to be in the future, = not where it is now. Some of us have been through signing headers in the wo= rld of DKIM. It was necessary but it certainly wasn't at all pleasant.<= /div>

So what I would like to s= ee WPACK do for its own sake even if it is never taken up in the world of H= TTP, is to introduce the structured separation of headers into functional u= nits that we wanted in HTTP/1.1 (Simon Spero tried) but couldn't do. In= other words instead of

C= onnection: Keep-Alive
Content-Type: text/html
Date: blah
Content-Encoding: gzip

We should have had (using JSON for clarity but at the time it wa= s S-expressions being discussed)

Connection: Keep-Alive
Date: blah=C2=A0=C2=A0
Content-Meta {
=C2=A0 "type&quo= t;:"text/html"
=C2=A0 "Con= tent-Encoding" : "gzip" }
=
If we had had this type of separatio= n, HTTP/1.1 would have been a lot easier.=C2=A0 =C2=A0

The protocol head= ers can and do change in transit. But if the content metadata had been coll= ected together in one place it should actually be unmolested end-to-end unl= ess the content itself had been changed. It does present the material in a = form that allows it to be signed.

I don't think the choice of JSON or CBO= R is particularly consequential. But the browser is going to have a JSON pa= rser which is why I focus on that.
=

Providing a ZIP like cap= ability does not require us to go any further than content metadata. But WP= ACK potentially requires a bit more as we are not just looking to display t= he content to the user, we want to push it into their browser cache. And so= it is not just the content and associated metadata that are at issue here,= it is also the binding of that data to the resource identifier. So what we= are looking at is actually something more like:

Resource {
=C2=A0 "expires" : "2019-dec-01: blah&quo= t;=C2=A0=C2=A0
=C2=A0 "Content-M= eta" : {
=C2=A0 =C2=A0 "type&qu= ot;:"text/html"
=C2=A0 =C2=A0 &= quot;Content-Encoding" : "gzip" }

And this could potentially be signed separate= ly in certain contexts.

<= br>

<= div class=3D"gmail_default" style=3D"font-size:small">
--0000000000002f86870596c7bbe1-- From nobody Sun Nov 17 02:40:12 2019 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 938C4120059 for ; Sun, 17 Nov 2019 02:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 8CNUmgXoxrVg for ; Sun, 17 Nov 2019 02:40:09 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 D308E12004D for ; Sun, 17 Nov 2019 02:40:08 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id o11so16603120qtr.11 for ; Sun, 17 Nov 2019 02:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=g+FJ+3q9I1nqmDH4KS6NOMFyJP4V0JlQqzd9q19e6x0=; b=jwfmI6KlX0XaXY25w1vkUYqueLOBHc8w3Tu6aZF2T+9Z59egIeybF+/gQ23j06fhcM FnolTJ9uMW2Xpwmi3Rw6LjNoH1n2ilGRK0el+rZR7WyoqC78/sshnP8X4JophUJDqKo2 /ayAm3qv7IQNuSYtexe3wTtxIFRXqcxMdjCTZt4jO2HqSIQMnVKLUQMZHAB/3zxeO74T amhW9CxSQ70umLXI2dQ+JaJc0KnQ1LJY/UuHS5QswaOsYSAgysa+aAj8Gv1pdigXvhe7 xpvYEZejXOrgucLnII6ur8DpPzcQD9v5+sKF3+miadjJnT8bJiOYmj8mN4sHruNLXWMb nRfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=g+FJ+3q9I1nqmDH4KS6NOMFyJP4V0JlQqzd9q19e6x0=; b=hFLon0XsDdL9oczSo/g01E+7CxGR0Q7X69TyXFHaWpjGmmdls/wMveoBm/Mx6L98JK xFe9ZDSZuwX6xcEEG6THOyXzeyIkD8u9UeS7mexP9Yzap6+VtgUyKDPZ7PmFpRl/NFGf atSVlcGlN3mMtH7oFKbNYEsXkoinkcB/S7ub7qW4cjgPv0UkbrM/Y27+WPPc/EYY0NtX pzou7Ve/DsfPV1/sP8Qvzuv1TpiwUcNPDMuIeEDKLAqnzZGJ0oUrtpAYOSyAIciAxbuX VRbpRtBdzUwqS8yuVbbzBi/aCw8QoVCT602PlXbMcOSMdRj6YVlAadC3zqpEqrmN7svy WhFQ== X-Gm-Message-State: APjAAAVusT3ucUtjzb3/7T+ewDV97U/eqgDuw3p3iWelODPjwHVe5Bgw enlnSiMLq9nHzMESDHQXbNOOCkd0X/F0hyj0k2gBAasB2XMzIY35 X-Google-Smtp-Source: APXvYqwrEFCzQAEunA4cNw7BLTTwtpe1v1RWQMdvuiAcmSRAxCfvraKq9jyP9riS/fn0q8o7Jj1fqIhaApK9V9uXS34= X-Received: by 2002:ac8:30ea:: with SMTP id w39mr22395735qta.250.1573987207017; Sun, 17 Nov 2019 02:40:07 -0800 (PST) MIME-Version: 1.0 From: Jeffrey Yasskin Date: Sun, 17 Nov 2019 18:39:55 +0800 Message-ID: To: wpack@ietf.org Content-Type: multipart/alternative; boundary="0000000000005b6cce059788747c" Archived-At: Subject: [Wpack] Bundle demo 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: Sun, 17 Nov 2019 10:40:11 -0000 --0000000000005b6cce059788747c Content-Type: text/plain; charset="UTF-8" If you're at the IETF meeting, have an Android phone, and want to try out the peer-to-peer bundle sharing use case: 1. Install Chrome Canary: https://play.google.com/store/apps/details?id=com.chrome.canary 2. Enable the Web Bundles flag: chrome://flags/#web-bundles 3. Install a peer-to-peer file transfer app. I have Xender , SHAREit , and Files by Google . 4. Find me (or someone else who has already found me). Jeffrey --0000000000005b6cce059788747c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you're at the IETF meeting, have an Android phone, = and want to try out the peer-to-peer bundle sharing use case:

2. Enable the Web Bundles flag= :=C2=A0chrome://flags/#web-bundles
3. Install a peer-to-pe= er file transfer app. I have Xender,=C2=A0SHAREit, and=C2=A0Files by Google.
4. Find me (or someone else = who has already found me).

Jeffrey
--0000000000005b6cce059788747c-- From nobody Sun Nov 17 07:29:17 2019 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 B2B85120112 for ; Sun, 17 Nov 2019 07:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ducksong.com header.b=m/XMqY+D; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=KyxCmLDD 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 HngJx3eW0gND for ; Sun, 17 Nov 2019 07:29:13 -0800 (PST) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A67B12006D for ; Sun, 17 Nov 2019 07:29:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574004552; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=lVkRnHE114fmd6OeBC+LAz8nMzsUhb/lwZBQJBymPciEOA/RnXxsNVlsDwBjesRntC/wxZdqN9trO rsftbqu59eO5AOFRx/pn5WsjEQTPCZlAWoBT48VUePGHb4FcdG6sIxsvJbeVX+5SavcJJD08msrwyR O+B5MGfwEQ/keoGXmvvqu/ydUIajvpnksHryyLgGLB6FVUuXDTq0fIsvtdgNwhx9WcZHJzxqVVJNmU OrTfxQwjrHyFQyAIrvpoA2XuwfXSFf2LM75wwlJvp/avTgfDH4Zf51Gw1gZXSGJZN2sZWtufMI5Ct/ piSNw4EjI9GF7b90t0dM9gtXEWUJvfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:to:subject:message-id:date:from:mime-version:dkim-signature: dkim-signature:from; bh=1Wr/PVaO6PHZo8lria/zDqnR9Ecci06OlI/rhdQ5670=; b=URP3FqkoAEC3tlTjWMQVLvGrQTufDNj2AZBEC2meVL+OZQ5Ej/Wo/qHLpD0RD82iZzIQ+BSLqHbC8 BT7Ujrfqi7Pr7gX8g1tM3crCli9Ki++hKHdmlRJ5A4IbwBgA6PhFQj2Rccn5gy21yOBAqV3i8jfbuQ /HRt+OzZa0eX3KKjjuh+wdKMQEsroxTHmT6sjXPHTbMwqTtAz3ruq67icL+mfvG7Fv4QeyQS5XaqJI 1P2K63I1IEYFgNAUgfit3ODh7t27HYM4w9Ev2hSbjeBakzaeeeeTZYRD3S71ewzetA45gU8liZgzHI LcN0UCpkwi+asbNNTnGKYm1FoWMxu5g== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.172; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:to:subject:message-id:date:from:mime-version:from; bh=1Wr/PVaO6PHZo8lria/zDqnR9Ecci06OlI/rhdQ5670=; b=m/XMqY+DnKdZ4E5zmxtMGXqrYyNkf+0I+IjeiR5Te2DCQ//YZOjxNsi0bDZ2RiVTxa5iPArpHB3p/ rhlEOLstGFGnz5vdFfuuyH2H1tvM2uw8MjHUbhSQ3RKfhzi+qkh3lVZYSUXGhx9X/UWk0HO9b2hcKf k/bUOSiEuwIcZicM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:to:subject:message-id:date:from:mime-version:from; bh=1Wr/PVaO6PHZo8lria/zDqnR9Ecci06OlI/rhdQ5670=; b=KyxCmLDDbYMN/14GUIEEm+1ouI4hQYwoMIJnJc4YjqyCTnKQ2K9gis0BVOsoGumHSqtnwJy8XV969 pSnXm/77bJFx9SWNhscAK/0CCsLB1WGgu6xssa5PZ+UCDW208/xFeatdzXwC6iVMpATe4QWFE0ZMVj tnxaiMpI6CIxSVi3m/qW6kChSp8+im/zvwZfSo8lrY+4Mce06UYQgDFtswm8oJFCMF0ntQBuV9sdHI oITdPYsgvwU1ZJEgb4SwCy4TzAJzG038ayRZ2G9YLyos1zyRuqVm9kB8MIqxLCfLkjbqn9yVY9IpKS 9kYh7vnOgscw3ul+vFpf4zsp32+z8Yg== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 008dbb19-094f-11ea-829e-79a40d15cccd X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.167.172 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-oi1-f172.google.com (unknown [209.85.167.172]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 008dbb19-094f-11ea-829e-79a40d15cccd; Sun, 17 Nov 2019 15:29:11 +0000 (UTC) Received: by mail-oi1-f172.google.com with SMTP id n16so13023475oig.2 for ; Sun, 17 Nov 2019 07:29:10 -0800 (PST) X-Gm-Message-State: APjAAAWFEdOfub7+ZZnRlNbV1H+rLTtEHBYObMlXm7SXdd9mUfWAG7dc cvHAHYxLVnHscZTn3AlcaK+m4poZMYTRdv+Ey60= X-Google-Smtp-Source: APXvYqyadke36mvai0nDGFtdAOLucdnttdgVEWIIUpQ6W5r6uhL+/epwT0sMp8d1jZKWKd/5oQ7//pmHvZ0dMGDQqDA= X-Received: by 2002:aca:a842:: with SMTP id r63mr15787979oie.118.1574004550221; Sun, 17 Nov 2019 07:29:10 -0800 (PST) MIME-Version: 1.0 From: Patrick McManus Date: Sun, 17 Nov 2019 23:28:59 +0800 X-Gmail-Original-Message-ID: Message-ID: To: wpack@ietf.org Content-Type: multipart/alternative; boundary="00000000000017459005978c7e94" Archived-At: Subject: [Wpack] WPACK BoF Notes 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: Sun, 17 Nov 2019 15:29:16 -0000 --00000000000017459005978c7e94 Content-Type: text/plain; charset="UTF-8" Hi All, I have few notes to share with the list in the role of chair for Wednesday's BoF.. The proponents have updated their proposed charter a little bit. As this is a potentially WG forming BoF we'll be talking about that proposal extensively - it is located here as part of the meeting materials: https://datatracker.ietf.org/meeting/106/materials/slides-106-wpack-proposed-charter-00-01 .and I will reply to this message with a copy of it to seed any discussion beforehand. Feel free to comment on the list ahead of time if you like - there are fewer time constraints on the list of course. Likewise, several of the presentations have been posted (3 of 5 I believe) and I expect the others to be available on Monday. The meeting materials in general, including these slides, are https://datatracker.ietf.org/meeting/106/session/wpack Before the meeting please make sure to read https://tools.ietf.org/html/draft-iab-escape-report-00 which is the report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE). Our agenda, as of this time, is below. I look forward to our meeting on Wednesday - see .you then! -Patrick # Overview * IETF 106 - WPACK (Web Packaging) BoF * 15:20 - 16:50 Wednesday Afternoon session II Room Collyer * Minutes: https://etherpad.ietf.org/p/notes-ietf-106-wpack?useMonospaceFont=true * BoF Proposal: https://trac.tools.ietf.org/bof/trac/wiki/WPACK * BoF Proposed Charter: https://github.com/WICG/webpackage/blob/master/IETF-WG-charter.md * Mailing List Archive: https://mailarchive.ietf.org/arch/browse/wpack/ * Related Background: IAB ESCAPE Workshop report https://datatracker.ietf.org/doc/draft-iab-escape-report/ # Agenda * 5min Introduction -- Chair ## Background Presentations: * 5min Community Networking Use Cases -- Spencer Sevilla and Matt Johnson * 5min Pre-installed Websites Use Cases-- Brian Kardell (remotely) * 5min AMP Use Cases -- Devin Mullins * 5min Unsigned Bundle Sharing Use Cases -- Kinuko Yasuda (maybe remotely) ## Looking Forward * 10min Use Case Discussion * 10min Proposed Approach -- Jeffrey Yasskin * 10min General Clarification and Discussion * 20min Charter Review and Discussion * 15min BoF Polls -- Chair --00000000000017459005978c7e94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I have few notes to share with = the list in the role of chair for Wednesday's BoF..

The proponents have updated their proposed charter a little bit. As t= his is a potentially WG forming BoF we'll be talking about that proposa= l extensively - it is located here as part of the meeting materials:=C2=A0<= a href=3D"https://datatracker.ietf.org/meeting/106/materials/slides-106-wpa= ck-proposed-charter-00-01">https://datatracker.ietf.org/meeting/106/materia= ls/slides-106-wpack-proposed-charter-00-01=C2=A0.and I will reply to th= is message with a copy of it to seed any discussion beforehand. Feel free t= o comment on the list ahead of time if you like - there are fewer time cons= traints on the list of course.

Likewise, several o= f the presentations have been posted (3 of 5 I believe) and I expect=C2=A0t= he others to be available on Monday. The meeting materials in general, incl= uding these slides, are=C2=A0https://datatracker.ietf.org/meeting/106/session/wpack=

Before the meeting=C2=A0please make sure to r= ead=C2=A0https://tools.ietf.org/html/draft-iab-escape-report-00=C2=A0which is t= he report from the IAB Workshop on Exploring Synergy between Content Aggreg= ation and the Publisher Ecosystem (ESCAPE).

Our ag= enda, as of this time, is below. I look forward to our meeting on Wednesday= - see .you then!

-Patrick
# Overview

* IETF 106 - WPACK (Web Packaging) BoF
* 15:20 - 16:50	Wednesday Afternoon session II Room Collyer

* Minutes: https://etherpad.ietf.org/p/notes-ietf-106-wpack?useMo=
nospaceFont=3Dtrue
* BoF Proposal: https://trac.tools.ietf.org/bof/trac/wiki/WPACK
* BoF Proposed Charter: https://github.com/WICG/webpackage/blob/master/I=
ETF-WG-charter.md
* Mailing List Archive: https://mailarchive.ietf.org/arch/browse/wpack/
* Related Background: IAB ESCAPE Workshop report https://datatracker.ietf.org/do=
c/draft-iab-escape-report/

# Agenda

* 5min Introduction -- Chair

## Background Presentations:
* 5min Community Networking Use Cases -- Spencer Sevilla and Matt Johnson
* 5min Pre-installed Websites Use Cases-- Brian Kardell (remotely)
* 5min AMP Use Cases -- Devin Mullins
* 5min Unsigned Bundle Sharing Use Cases -- Kinuko Yasuda (maybe remotely)

## Looking Forward

* 10min Use Case Discussion

* 10min Proposed Approach -- Jeffrey Yasskin

* 10min General Clarification and Discussion

* 20min Charter Review and Discussion

* 15min BoF Polls -- Chair

--00000000000017459005978c7e94-- From nobody Sun Nov 17 07:31:48 2019 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 B44D1120111 for ; Sun, 17 Nov 2019 07:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ducksong.com header.b=r1JxEDYo; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=eFyrn5rw 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 9wZHbOMgvfcX for ; Sun, 17 Nov 2019 07:31:42 -0800 (PST) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EFF112006D for ; Sun, 17 Nov 2019 07:31:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574004701; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=ubzLcS+NO5MsmqtBl7YhC0gw5iGZ3VPkci/iZVkYN1P6dcUmOi8ITO4itygfySCpEsHrIoOGztxxW XQ9XB6kxhJjnwRb45jfQt6mw2l2GPXEs8MVZTHPT/orx3sKUFa0Y1ljp0zhSwW0jjhMurnAxwTsPbb DPdH1uhyPciNEOs4zSx/ruLo1VZBEl50uVvRcNHwGdCswIG28yg92WjGuAiYFVgLeTZTBAB6IRnb5X ksO8wnkR0r5yIDPlDHuiDfXECHiUA4YmPTZBuYRt+G+up22sfalr1Z9XwFkRYRPh/DOGycMkCVJB72 bnJMlXthrktB/dUmz6q0+fUYz52CHbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=Yk5Z8dgXeBglHRYgM0mYACz05xJdVBazGjUnbRbMOsY=; b=RNaatatGiD03R7QQmq/XF5tiP6zJE+Zamv0prwgJqD7+1XRFNZFUN/lvbTZmqsxD6YsWgJE40uffn i60qhsG++vED9GN9iU9ZOELM+lsFBEldIKa8Ob/fExYEbVRnVAYj+QClXvkmQCeXWJrPnFa1/mMBj2 np4NIwU0m0Gmo2FYlqkpoXU7xVBq3TUYd8dqNCz8pxrR4aPUOyB9bnvhKLbSuoEpsrqe+Pm7Yw3N8b zG6qP9e6MUgvKbgkA6TuWb4xaBE5VaO4w2KbDhPLGE3eDV8C5qyvveJ/Hzj1u+fQVZ5lJzsuIDQjLT 3RnZzvcqihLUf3lsY1TRIfO7Bb2YJMQ== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.182; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=Yk5Z8dgXeBglHRYgM0mYACz05xJdVBazGjUnbRbMOsY=; b=r1JxEDYo+m8vDmShaQ/bmMqtUfSLorTYv0qqw71QrGbSN6uZhY4jwE3mXiPYfiOOAAPYBmcpNC5Sv yv3NAav1bfnOvkSHe1vOLnVJcEVU4Qtxhy9TbVAAikJOwcvEjuXkRzB49/1s6TZ/x7+kkkmppm1aA4 vnR736lE5UWwRyso= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=Yk5Z8dgXeBglHRYgM0mYACz05xJdVBazGjUnbRbMOsY=; b=eFyrn5rwtx7UaU165dXwuSNkVJtODu3Oeg2xywnT51XmTdREoKArFInS3GsgT8d3AfexveseIyA6l tYfBv/ly7U0sO/Sh496HoTSzV5OAwgcqpBFA34+OrC4wgGXotSPfg+2H30r1z4VJCHKEMK0i2wavAS y10ndJrCp8CQNdKT4aX4FGm/c1dmBD1qX7SJTxVeSGwGxaNAz4cYxY5xc+wgYPmK5iBDWMsyELoiEa Qs7YyEd3cWDFgdJK5w4QT5dVf9AtNuyjUqFSY7PKbwYjVWlNa1XlUpB4KHQRnS6/TjxHnd2Mtc95Hj eB9P9DQ3DVeWbJZRluxFUbTSWdF3J7A== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 587999ae-094f-11ea-b80c-052b4a66b6b2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.167.182 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-oi1-f182.google.com (unknown [209.85.167.182]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 587999ae-094f-11ea-b80c-052b4a66b6b2; Sun, 17 Nov 2019 15:31:39 +0000 (UTC) Received: by mail-oi1-f182.google.com with SMTP id y194so13031987oie.4 for ; Sun, 17 Nov 2019 07:31:38 -0800 (PST) X-Gm-Message-State: APjAAAW0SweeV2MtUmOPwJugYGkth4IMXuPqqRkW0nTcqfy190N78Gaw EtYLNRH4FJkUIdQ6k26OjSZCHrIBmJGfwI0llqQ= X-Google-Smtp-Source: APXvYqy0J3oEk+vwcbMUMSTbY354EkEROLmoG92XKv6c6Fx1GjXrra+MEnAG2wNG/B9k2GGDdHw+3Lm+E9GPQhhHcBk= X-Received: by 2002:aca:b105:: with SMTP id a5mr16664593oif.82.1574004697670; Sun, 17 Nov 2019 07:31:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Patrick McManus Date: Sun, 17 Nov 2019 23:31:26 +0800 X-Gmail-Original-Message-ID: Message-ID: To: Patrick McManus Cc: wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000e12c9605978c86cd" Archived-At: Subject: Re: [Wpack] WPACK BoF Notes 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: Sun, 17 Nov 2019 15:31:46 -0000 --000000000000e12c9605978c86cd Content-Type: text/plain; charset="UTF-8" This is the WPACK proposed charter text, also available at https://github.com/WICG/webpackage/blob/0b0a67a71c983b9dc91f89edf8ebb2a5758568b3/IETF-WG-charter.md -Patrick Background Webpages sometimes group multiple subresources into a single combined resource to allow cross-resource compression and to reduce the overhead of HTTP/1 requests. The W3C TAG (Technical Architecture Group) proposed a web packaging format based on multipart/* , to give web browsers visibility into the substructure of these combined resources. That has not seen deployment and HTTP/2 did not make these bundles unnecessary as was once expected. These bundles are still needed. In countries with expensive and/or unreliable mobile data, there is an established practice of sharing content and native applications peer-to-peer. Untrusted web content can generally be shared, but with the web's move to HTTPS, it is no longer possible to share web apps over these channels WPACK The WPACK working group will develop a specification for a web packaging format that efficiently bundles multiple HTTP resources. It will also specify a way to optionally sign these resources such that a user agent can trust that they came from their claimed web origins. Key goals for WPACK are: - Efficient storage across a range of resource combinations. Three examples to be supported are: a client-generated snapshot of a complete web page, a web page's tree of JavaScript modules, and El Paquete Semanal from Cuba. - Safe web app installation after having been retrieved from a peer. - Low latency to load a subresource from a package, whether the package is signed or unsigned, and whether the package is streamed or loaded from random-access storage. - Being extensible, including to avoid cryptography that becomes obsolete. - Security and privacy properties of using bundles as close as practical to TLS 1.3 transport of the same resources. Where properties do change, the group will document exactly what changed and how content authors can compensate. - A low likelihood that the new format increases centralization or power imbalances on the web. The packaging format will also aim to achieve the secondary goals described in draft-yasskin-wpack-use-cases as long as they don't compromise or delay the above properties. The following potential goals are out of scope under this charter: - DRM - A way to distribute the private portions of a website. For example, WPACK might define a way to distribute Gmail's application but wouldn't define a way to distribute individual emails without a direct connection to Gmail's origin server. - Defining the details of how web browsers load the formats and interact with any protocols we define here. - A way to automatically discover the URL for an accessible package that includes specific content. Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set (consisting of draft-yasskin-wpack-use-cases, draft-yasskin-wpack-bundled-exchanges, and draft-yasskin-http-origin-signed-responses) does not imply that there is consensus around the feature or around how it is specified. Relationship to Other WGs and SDOs WPACK will work with the W3C and WHATWG to identify the existing security and privacy models for the web, and to ensure those SDOs can define how this format is used by web browsers. Milestones - Chartering + 3 Months: Working group adoption of use cases document - Chartering + 3 Months: Working group adoption of bundling document - Chartering + 3 Months: Working group adoption of security analysis document - Chartering + 3 Months: Working group adoption of privacy analysis document - Chartering + 3 Months: Working group adoption of signing document - Chartering + 18 Months: Use cases document to IESG - Chartering + 18 Months: Bundling document to IESG - Chartering + 24 Months: Security analysis document to IESG - Chartering + 24 Months: Privacy analysis document to IESG - Chartering + 24 Months: Signing document to IESG On Sun, Nov 17, 2019 at 11:28 PM Patrick McManus wrote: > Hi All, > > I have few notes to share with the list in the role of chair for > Wednesday's BoF.. > > The proponents have updated their proposed charter a little bit. As this > is a potentially WG forming BoF we'll be talking about that proposal > extensively - it is located here as part of the meeting materials: > https://datatracker.ietf.org/meeting/106/materials/slides-106-wpack-proposed-charter-00-01 .and > I will reply to this message with a copy of it to seed any discussion > beforehand. Feel free to comment on the list ahead of time if you like - > there are fewer time constraints on the list of course. > > Likewise, several of the presentations have been posted (3 of 5 I believe) > and I expect the others to be available on Monday. The meeting materials in > general, including these slides, are > https://datatracker.ietf.org/meeting/106/session/wpack > > Before the meeting please make sure to read > https://tools.ietf.org/html/draft-iab-escape-report-00 which is the > report from the IAB Workshop on Exploring Synergy between Content > Aggregation and the Publisher Ecosystem (ESCAPE). > > Our agenda, as of this time, is below. I look forward to our meeting on > Wednesday - see .you then! > > -Patrick > > # Overview > > * IETF 106 - WPACK (Web Packaging) BoF > * 15:20 - 16:50 Wednesday Afternoon session II Room Collyer > > * Minutes: https://etherpad.ietf.org/p/notes-ietf-106-wpack?useMonospaceFont=true > * BoF Proposal: https://trac.tools.ietf.org/bof/trac/wiki/WPACK > * BoF Proposed Charter: https://github.com/WICG/webpackage/blob/master/IETF-WG-charter.md > * Mailing List Archive: https://mailarchive.ietf.org/arch/browse/wpack/ > * Related Background: IAB ESCAPE Workshop report https://datatracker.ietf.org/doc/draft-iab-escape-report/ > > # Agenda > > * 5min Introduction -- Chair > > ## Background Presentations: > * 5min Community Networking Use Cases -- Spencer Sevilla and Matt Johnson > * 5min Pre-installed Websites Use Cases-- Brian Kardell (remotely) > * 5min AMP Use Cases -- Devin Mullins > * 5min Unsigned Bundle Sharing Use Cases -- Kinuko Yasuda (maybe remotely) > > ## Looking Forward > > * 10min Use Case Discussion > > * 10min Proposed Approach -- Jeffrey Yasskin > > * 10min General Clarification and Discussion > > * 20min Charter Review and Discussion > > * 15min BoF Polls -- Chair > > > --000000000000e12c9605978c86cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

-Patrick
=


=

Background

Webpages sometimes group multiple subre= sources into a single combined resource to allow cross-resource compression= and to reduce the overhead of HTTP/1 requests. The W3C TAG (Technical Arch= itecture Group) proposed a web packaging format based on multipart/* , to g= ive web browsers visibility into the substructure of these combined resourc= es. That has not seen deployment and HTTP/2 did not make these bundles unne= cessary as was once expected.

These bundles are stil= l needed. In countries with expensive and/or unreliable mobile data, there = is an established practice of sharing content and native applications peer-= to-peer. Untrusted web content can generally be shared, but with the web= 9;s move to HTTPS, it is no longer possible to share web apps over these ch= annels

WPACK

The WPACK work= ing group will develop a specification for a web packaging format that effi= ciently bundles multiple HTTP resources. It will also specify a way to opti= onally sign these resources such that a user agent can trust that they came= from their claimed web origins. Key goals for WPACK are:

  • Efficient stora= ge across a range of resource combinations. Three examples to be supported = are: a client-generated snapshot of a complete web page, a web page's t= ree of JavaScript modules, and El Paquete Semanal from Cuba.
  • Safe web app installation afte= r having been retrieved from a peer.
  • Low latency to load a subresource from a package, wheth= er the package is signed or unsigned, and whether the package is streamed o= r loaded from random-access storage.
  • Being extensible, including to avoid cryptography that = becomes obsolete.
  • Security and privacy properties of using bundles as close as practical to = TLS 1.3 transport of the same resources. Where properties do change, the gr= oup will document exactly what changed and how content authors can compensa= te.
  • A low likelih= ood that the new format increases centralization or power imbalances on the= web.

The packaging format will also aim to ac= hieve the secondary goals described in draft-yasskin-wpack-use-cases as lon= g as they don't compromise or delay the above properties.

The following potential goals are out of scope under this chart= er:

  • DRM
  • A way t= o distribute the private portions of a website. For example, WPACK might de= fine a way to distribute Gmail's application but wouldn't define a = way to distribute individual emails without a direct connection to Gmail= 9;s origin server.
  • Defining the details of how web browsers load the formats and interact wi= th any protocols we define here.
  • A way to automatically discover the URL for an accessible p= ackage that includes specific content.

Note th= at consensus is required both for changes to the current protocol mechanism= s and retention of current mechanisms. In particular, because something is = in the initial document set (consisting of draft-yasskin-wpack-use-cases, d= raft-yasskin-wpack-bundled-exchanges, and draft-yasskin-http-origin-signed-= responses) does not imply that there is consensus around the feature or aro= und how it is specified.

Relationship to Other WGs and SDOs

WPACK will work with the W3C and WHATWG to identify the exi= sting security and privacy models for the web, and to ensure those SDOs can= define how this format is used by web browsers.

Milestones

  • Chartering + 3 Months: Working group adoption of use c= ases document
  • Cha= rtering + 3 Months: Working group adoption of bundling document
  • Chartering + 3 Months: Worki= ng group adoption of security analysis document
  • Chartering + 3 Months: Working group adoptio= n of privacy analysis document
  • Chartering + 3 Months: Working group adoption of signing docu= ment
  • Chartering += 18 Months: Use cases document to IESG
  • Chartering + 18 Months: Bundling document to IESG
  • Chartering + 24 Mont= hs: Security analysis document to IESG
  • Chartering + 24 Months: Privacy analysis document to = IESG
  • Chartering += 24 Months: Signing document to IESG

On Sun, Nov 17, 2019 at 11:28= PM Patrick McManus <mcmanus@duc= ksong.com> wrote:
Hi All,

I have few notes to = share with the list in the role of chair for Wednesday's BoF..

The proponents have updated their proposed charter a littl= e bit. As this is a potentially WG forming BoF we'll be talking about t= hat proposal extensively - it is located here as part of the meeting materi= als:=C2=A0https://datatracker= .ietf.org/meeting/106/materials/slides-106-wpack-proposed-charter-00-01= =C2=A0.and I will reply to this message with a copy of it to seed any discu= ssion beforehand. Feel free to comment on the list ahead of time if you lik= e - there are fewer time constraints on the list of course.

<= /div>
Likewise, several of the presentations have been posted (3 of 5 I= believe) and I expect=C2=A0the others to be available on Monday. The meeti= ng materials in general, including these slides, are=C2=A0https:/= /datatracker.ietf.org/meeting/106/session/wpack

Before the meeting=C2=A0please make sure to read=C2=A0https://t= ools.ietf.org/html/draft-iab-escape-report-00=C2=A0which is the report = from the IAB Workshop on Exploring Synergy between Content Aggregation and = the Publisher Ecosystem (ESCAPE).

Our agenda, as o= f this time, is below. I look forward to our meeting on Wednesday - see .yo= u then!

-Patrick
# Overview

* IETF 106 - WPACK (Web Packaging) BoF
* 15:20 - 16:50	Wednesday Afternoon session II Room Collyer

* Minutes: https://etherpad.ietf.org/p/notes-ie=
tf-106-wpack?useMonospaceFont=3Dtrue
* BoF Proposal: https://trac.tools.ietf.org/bof/trac/wiki/WPACK
* BoF Proposed Charter: https://github.com/WICG/webpac=
kage/blob/master/IETF-WG-charter.md
* Mailing List Archive: https://mailarchive.ietf.org/arch/browse/wpack/<=
/a>
* Related Background: IAB ESCAPE Workshop report https://datat=
racker.ietf.org/doc/draft-iab-escape-report/

# Agenda

* 5min Introduction -- Chair

## Background Presentations:
* 5min Community Networking Use Cases -- Spencer Sevilla and Matt Johnson
* 5min Pre-installed Websites Use Cases-- Brian Kardell (remotely)
* 5min AMP Use Cases -- Devin Mullins
* 5min Unsigned Bundle Sharing Use Cases -- Kinuko Yasuda (maybe remotely)

## Looking Forward

* 10min Use Case Discussion

* 10min Proposed Approach -- Jeffrey Yasskin

* 10min General Clarification and Discussion

* 20min Charter Review and Discussion

* 15min BoF Polls -- Chair

--000000000000e12c9605978c86cd-- From nobody Wed Nov 20 18:10:16 2019 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 47A2D120144 for ; Wed, 20 Nov 2019 18:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.406 X-Spam-Level: X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.244, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 XCKiW-1ZFJ2c for ; Wed, 20 Nov 2019 18:10:14 -0800 (PST) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (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 16D19120077 for ; Wed, 20 Nov 2019 18:10:14 -0800 (PST) Received: by mail-oi1-f175.google.com with SMTP id e9so1750578oif.8 for ; Wed, 20 Nov 2019 18:10:14 -0800 (PST) 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; bh=EETvR+5bE+LKQrlFKG6B+u/N4vXbfmh0dBBYfibSYw8=; b=INYt2Xjen9Ibb769t/ypeHQxB2KtQEVFdOulTM+rU5oXltMDLhbT7hA5u4BJ2GpjAM AMWhsu5LxAC8opmmnpyMxu4d1YTm4gi4X4ntzRD2Ir1ilfD3t4R0qLD16M9zG3LljMY0 w5u4HVL4HXe6orWR7H2sKvve8V3NlE8n78206paUZvpySJ5GD7uwQK1ZK8boiYQcepra zkJYCOWC7U2FLRcVOWQlle7cGTahkMd2HuN0peOjyQ/KyjFk1osUr1u88xbpmLnSMoD4 ZLG6SBleZ0g2Ms0JhXE7jozIVr4JTfAlBUugkp1fnkvxa6J8GZ81upB5Mr6J36XKnUIG 8PiA== X-Gm-Message-State: APjAAAVwZIZCuVfLozV4Ajm4KWG/d93cNtbcuDpjvHdiJBGmqb3POzPz +5uDxSkPaCSmT+XdtDPMEOweHak1ZDaLDAyEfIxgQQ1R X-Google-Smtp-Source: APXvYqz9fBZrFhIt9rkDxf2Z3qFV6K+haGoIvZVhuPIorSz1XNPefgZMFuVjEazpG+A2EB9ux/WJK6M3tg5JtO/Hx+4= X-Received: by 2002:aca:484e:: with SMTP id v75mr5633714oia.6.1574302212944; Wed, 20 Nov 2019 18:10:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Thu, 21 Nov 2019 10:10:00 +0800 Message-ID: To: wpack@ietf.org Content-Type: multipart/alternative; boundary="0000000000002bf7fb0597d1cc9b" Archived-At: Subject: [Wpack] Charter proposal 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, 21 Nov 2019 02:10:15 -0000 --0000000000002bf7fb0597d1cc9b Content-Type: text/plain; charset="UTF-8" I see three distinct pieces of work here. 1) The container encoding 2) Determining the correspondence to HTTP 3) Working out what signatures actually mean Developing an encoding format is relatively straightforward, we don't even need to pick a single one. If people are happy having separate encodings to support signed content and signed/encrypted content, that is fine with me. But if this group is chartered with encryption excluded from the encoding considerations, then that is a commitment to two encodings in perpetuity. With the best will in the world, merging the streams two years after they have diverged is a non-starter. So what I would like to see is encryption in scope for the WG but not decryption. And that is not a joke. Encryption is easy. The hard part is deciding how to decrypt. And that is a problem that is properly outside the scope of the WG. The Mathematical Mesh provides two separate decryption schemes. One is the use of EARLs, the other is a key distribution center scheme that gives a subset of DRM capabilities I call confidential document control (preventing redistribution of the plaintext is out of scope). And WPACK need not depend on the Mesh for decryption capabilities. Nor should it. All the package needs to do is to provide a means of identifying the key used for encryption (hash of the public key or the symmetric key), the key exchange information and provide an open extensible structure for throwing in whatever advice you might want. So I would like to see the 'DRM' etc. parts removed from the charter scope and instead have encryption in scope and decryption out of scope. Now the question we might want to consider is whether the same should be true for the interpretation of signatures... I am not sure. It is certainly a large and complex piece of work and the HTTP part is also large and complex. --0000000000002bf7fb0597d1cc9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I s= ee three distinct pieces of work here.

1) The container encoding
2) Determining the correspondence to HTTP
3) Working out what sig= natures actually mean

Dev= eloping an encoding format is relatively straightforward, we don't even= need to pick a single one. If people are happy having separate encodings t= o support signed content and signed/encrypted content, that is fine with me= .

But if this group is ch= artered with encryption excluded from the encoding considerations, then tha= t is a commitment to two encodings in perpetuity. With the best will in the= world, merging the streams two years after they have diverged is a non-sta= rter.=C2=A0
So what I wou= ld like to see is encryption in scope for the WG but not decryption. And th= at is not a joke. Encryption is easy. The hard part is deciding how to decr= ypt. And that is a problem that is properly outside the scope of the WG.

The Mathematical Mesh provi= des two separate decryption schemes. One is the use of EARLs, the other is = a key distribution center scheme that gives a subset of DRM capabilities I = call confidential document control (preventing redistribution of the plaint= ext is out of scope).=C2=A0

And WPACK need not depend on the Mesh for decryption capabilities. Nor s= hould it. All the package needs to do is to provide a means of identifying = the key used for encryption (hash of the public key or the symmetric key), = the key exchange information and provide an open extensible structure for t= hrowing in whatever advice you might want.

So I would like to see the 'DRM' etc. parts remov= ed from the charter scope and instead have encryption in scope and decrypti= on out of scope.=C2=A0

No= w the question we might want to consider is whether the same should be true= for the interpretation of signatures... I am not sure. It is certainly a l= arge and complex piece of work and the HTTP part is also large and complex.= =C2=A0
--0000000000002bf7fb0597d1cc9b-- From nobody Wed Nov 20 20:37:00 2019 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 1DB3012023E for ; Wed, 20 Nov 2019 20:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ducksong.com header.b=H7f1ZZ8E; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=bQ1r8DjR 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 GsQlLQfQrzEE for ; Wed, 20 Nov 2019 20:36:57 -0800 (PST) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206FC12002E for ; Wed, 20 Nov 2019 20:36:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574311017; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=Ntu9kEYX5TZqs8TCDIPCXOYwdXp/aJJ3+yth1uWKalPxPRT5tAoYRp3yvyBsgotszN9xId8JrN5dZ s+dk0jwiAZgqCbmTTyf54EnM3Wy1cQrDVeW10HiByLR5oOHRQuIS57ETS+BHhRNICSv7R9OpVNVn47 12kdd6c61iwDXsxDEvCRCuFX0n8JEBURHHbzcqHQfIYuf+EhMnn2YRaL7TOVcAi3H3+R/DuRUY0ssJ ySLKom0MdC5/Q8HnzAdpKX88M2SRvb1yr8kW8PpGEYinBD3YkiFM5vObVOecHY2dwTJflHo88cX/T6 I9LSL4ifwhPeIiRbH4jsaBH9wEPXNRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:to:subject:message-id:date:from:mime-version:dkim-signature: dkim-signature:from; bh=1MvxGnpWHaQPgjc6xGZ/xcIdSn8Wa8paC9xt/7TEFGU=; b=FBL1bAvOlFYFYiZn8CWsJJHjVHJ7RH7DqDKE/bCKyv6to5ASLdo5U1geHCuJUg0SNBAI2yXQO1tGZ EQWmTxB4Yg0YKPOpcdX6rJX4EzFj8/LyaEN06AmUM9yq/lp7MkGsag0rrp9SLCgtdyln5UjBEY30+P B5duRvyJleWzJLaEak4gaxPILr6WJn+pYeedy89SY3d/usucdvPcwQrTDMBGRHhdW9THv/Ed88Gfnm Weqgvna/6JBJPgHjntOaPTGP5dJ74IQjiS16p2hIbrOdRALlmpIqcKt4GqTo6Dbc9jDBAXwXohg5VK UCLMds86CUsZveVe7gimZ5gWzuZMUQw== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.54; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:to:subject:message-id:date:from:mime-version:from; bh=1MvxGnpWHaQPgjc6xGZ/xcIdSn8Wa8paC9xt/7TEFGU=; b=H7f1ZZ8Em8zUPbARN/bGzHQQdiLD5HdXUILnES0WX2cjbhREht3EAIEI8Hlloena1RV0Q+uh8J78G NpSSq2lJEHDzZdVEEt9TvWjthXYUuCSDztycaDbMb1TJnc1G7fZpdj4xjY/ReHXCpDiR2WyBkPfQSh d/EL7DeFNPoPPswg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:to:subject:message-id:date:from:mime-version:from; bh=1MvxGnpWHaQPgjc6xGZ/xcIdSn8Wa8paC9xt/7TEFGU=; b=bQ1r8DjRmrqodfUtZCr5kkVOdDcPeR9f/ApoEvAahTk5kPJeEdELkavVAv34cfKfQYh9L5j9BVNoK //ASVUSiqzaJ1qqhNpSftZAWRnIiH9g64WITyA/QlU7rldF9a3hcKuA0hxtQgzWCk+vSvmK8Ez1WxX AK86CILRCJTa+HwTlT2RHSjv+gMAiQOABVeVkiEjKu4lMi13WofMRTysLlOG/tlbP2rpL8ZUBeni93 kYUZufzntjBff4PHoqmR+UvYf5+iKJ/E2Yrx9ggMbkPcxkD7F2v07XXr0qciKjQx1l8mdCZj1imOCu s24ZevqfR24eE/mBffW+nGHcPwtJbbw== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 8bb79f8b-0c18-11ea-b80c-052b4a66b6b2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.210.54 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f54.google.com (unknown [209.85.210.54]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 8bb79f8b-0c18-11ea-b80c-052b4a66b6b2; Thu, 21 Nov 2019 04:36:55 +0000 (UTC) Received: by mail-ot1-f54.google.com with SMTP id m15so1761552otq.7 for ; Wed, 20 Nov 2019 20:36:55 -0800 (PST) X-Gm-Message-State: APjAAAWIrgmsU0T0Q6IcX8T9j6yBZ3vzR9r0I2R1JM4NARbKp4TGkryI jV+o4RIIPXzfmescCSZmQ0k5uyKmM2XV7AA2wPE= X-Google-Smtp-Source: APXvYqx3EWqR+lVWxLKgzE4fkyRORTeTfVW/40iYxOnrPcRRxuavAZitaYKFsCPbEfqHEnG6ukB3slmh9DQK4nEcOh0= X-Received: by 2002:a05:6830:1d8b:: with SMTP id y11mr4521738oti.45.1574311014870; Wed, 20 Nov 2019 20:36:54 -0800 (PST) MIME-Version: 1.0 From: Patrick McManus Date: Thu, 21 Nov 2019 12:36:43 +0800 X-Gmail-Original-Message-ID: Message-ID: To: wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000ceb7e10597d3d8e9" Archived-At: Subject: [Wpack] WPACK BoF @ 106 Minutes 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, 21 Nov 2019 04:36:59 -0000 --000000000000ceb7e10597d3d8e9 Content-Type: text/plain; charset="UTF-8" I would like to thank everyone for their contributions to yesterday's BoF. I have uploaded a -00 version of our minutes which were recorded faithfully by Lucas Pardue and Martin Duke (thank you again) despite the etherpad service failing during the session. Well done! https://datatracker.ietf.org/meeting/106/materials/minutes-106-wpack-00 If you have edits to this version of the minutes please send them along so they can be corrected. -Patrick --000000000000ceb7e10597d3d8e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to thank everyone for their contributions to = yesterday's BoF. I have uploaded a -00 version of our minutes which wer= e recorded faithfully by Lucas Pardue and Martin Duke (thank you again) des= pite the=C2=A0etherpad service failing during the session. Well done!
<= br>

If you have edits to t= his version of the minutes please send them along so they can be corrected.=

-Patrick

--000000000000ceb7e10597d3d8e9-- From nobody Wed Nov 20 20:43:50 2019 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 4FB3A12091C for ; Wed, 20 Nov 2019 20:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ducksong.com header.b=YMZkK0uy; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=J5M0aO8l 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 WZXPPlaQrqyU for ; Wed, 20 Nov 2019 20:43:47 -0800 (PST) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0544612023E for ; Wed, 20 Nov 2019 20:43:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574311426; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=CocefSn0U1BmSTB/h1cr14UJo4xt/I8DPDk1MgFSZiVgedJUninkbX8A/q0JzulT3hhISYOUxPFWs ZVgnWooXJKzSIGygM+zO3/mlFOIt5i5RwORujzn/duRv4H93HAxGn87Y0bgs2LJS4yBfeGq4woagPK tNHgL7Qzh2AOC5nvOF4BSDp7RrD9BwhUjMpQz53siJux229/EEMIuRPTeROxs2pHi9cGWVYVAqohl5 WQ62ozakClsMBXmkUSfFlCfHOamhsX5Z9ejvY75X2TZgvr+hXDc4XrNeeiMOe8GsnC10PUJW91KSV0 NJtuPrqPePPzp1e3Fr+v+hzSdiysdHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:to:subject:message-id:date:from:mime-version:dkim-signature: dkim-signature:from; bh=EQlRL7cFNxlWGsnytOaCE90y0cBdGfddQNApN2CceJI=; b=lxKcZE4wZ5+A/Ecl4u8ULwuag9XMksbKCXGBIpq/0Svejddcj2e7QCuD04FxtVYmkOzlA4JLtTuki dzD7irFV9Apm6dRdQ2pH7QA+Jgu5d8zDNzzsYz39zMIcBi1WjBLVOfyuSHzsYRZqRNY82O9ZS8A0O5 3KEduSAPHhLrexLaIUA6NQEl7iGobEmS/Hlr4BNX5wFwUvJpL9ISoOoZL/bXpAiDSFfwjG35yGYX5w ncPsdE3zn7JoDmMSMaTnPrkJJzzBdkuACnuXUHEKx56MxwD3otm9cfnZZf54OezQxGcZzGhItf4QBg 1v1HiPfq+kkLnqBVsNDWU/l5alg/hag== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.43; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:to:subject:message-id:date:from:mime-version:from; bh=EQlRL7cFNxlWGsnytOaCE90y0cBdGfddQNApN2CceJI=; b=YMZkK0uyJf/6g9y4qtaECo9qeH4xOPiS3VZ7uAEZ6srpimEUMjBgSHxIuXS4Ie7kfizhu3VrqiI7q Gg3EOHP7UGQX8E8slCAarWZJqjc1VPqvaYTqvcpY+1MTlHVx6+6SaHXaeOjqrtsnF6afHLq22sMu6G /pOXUCgf7FBC9HbY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:to:subject:message-id:date:from:mime-version:from; bh=EQlRL7cFNxlWGsnytOaCE90y0cBdGfddQNApN2CceJI=; b=J5M0aO8ltQ8HMIIms1Jlp4bjKaz+9D/eWRuFH/+JuPpRApXYQHbVA9WKLz1n49l4D3eQVYCFBLyVW JByu+8UAr8m3cMClYk0spv50Pm7cKAnvvVjCxK/atvkOOh5EhPr6o1VKht1v5JZ5opjw5wvVIlf3Fn lw8Pit8Mho3D7cr+uRA7HrFGGurFaYxm9dUw1+f3KuMl3MxogM36TwNpWD/9ckZVEVNkTxGBZYVfSF dteHtXMjO5NpFSZ4B+b267co38k8VWlsb9ziQ1VZuKz/riLYBimvFK8cjPcXMCbQejb3sVN7Gy6Yzy kW2G/NHyuRuICUMhlO1iX1ZHNs/+6Tw== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 7f488ac1-0c19-11ea-b80c-052b4a66b6b2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.210.43 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f43.google.com (unknown [209.85.210.43]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 7f488ac1-0c19-11ea-b80c-052b4a66b6b2; Thu, 21 Nov 2019 04:43:44 +0000 (UTC) Received: by mail-ot1-f43.google.com with SMTP id f10so1796759oto.3 for ; Wed, 20 Nov 2019 20:43:44 -0800 (PST) X-Gm-Message-State: APjAAAW1ccHBob0w48mXjGtjtqThX0826BaZT9IBooVRKpnnRem6ShuZ KL4nWh2UT3a8WS1tTx+KG51KBvyotF8Qi/u2pFs= X-Google-Smtp-Source: APXvYqzY/Qi87Scf1RezdWghrNa/mlZTexnmDUOONYP+EeO5pq/RlNy6sjTxF7PsVZISyneqG17WtG/TXcfOEd0ra7Q= X-Received: by 2002:a9d:7a86:: with SMTP id l6mr4848533otn.340.1574311423113; Wed, 20 Nov 2019 20:43:43 -0800 (PST) MIME-Version: 1.0 From: Patrick McManus Date: Thu, 21 Nov 2019 12:43:32 +0800 X-Gmail-Original-Message-ID: Message-ID: To: wpack@ietf.org Content-Type: multipart/alternative; boundary="0000000000002402330597d3f193" Archived-At: Subject: [Wpack] WPACK Charter Discussion 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, 21 Nov 2019 04:43:49 -0000 --0000000000002402330597d3f193 Content-Type: text/plain; charset="UTF-8" Thank you all for your professional contributions to the BoF yesterday where the consensus was that the BoF attendees did recommend the formation of a group using a charter derived from the comments presented in the room and to further refined on this list. At the BoF the group committed to further work on the charter as the IESG decides what to do with the outcome of the BoF. The document. in view-only now, that we annotated with comments during the session is available here for your reference https://docs.google.com/document/d/1murCu-Gp7cdgFfDFQM8p8kfnG2B7xFMgUQHD6Ib9Bh0/edit#heading=h.h5l6zialtryr The specific comments from the -00 revision of the minutes during the charter discussion portion of the meeting are also included inline here for your reference while you do your work. Charter Review and Discussion sean turner (opens google doc): now it's time for some group editing. [starts reading the charter draft aloud] MT: it is not true that we cannot secure web apps over constrained edge channels. mnot: last sentence of first paragraph will be read as "a bundle is required for performance", which is not true and recommend deleting it bishop: "the previous attempt to solve the problem was not deployed" please explain why jyasskin: answering martin, browsers require secure context and you don'tget that with files [to mark] there is a webpack program that is super-heavily used; you have to bundle to get good performance rpeon: bounced the WPACK idea of two folks that said this is not completely crazy. mention of H2 server push and it is pertinent to consider that mnot: solved by changing HTTP/2 to HTTP/2 server push? trammell: we're wordsmithing the background section ben schwarz: can we not refer to a specific thing in Cuba (el paquete semanal) trammell: can I comment on something you haven't read yet sean: no mnot: was web pack sufficiently defined, is a liason required trammell: [to aspects related to cryptography/security]I undesrtand where this came from and it gives me anxiety ted: this is not granular enough. must talk about handling of items in bundle as well. trammell: use the headings in the Jeffrey's slides peon: be more specific about security and privacy properties. bishop: don't drop a third example, just don't refer directly to a Cuban instance mcmanus: we should move to things out of scope dkg: the properties that TLS 1.3 provides goes away if someone else delivers the data mcmanus: are you suggesting a bar that the wg would have to meet? dkg: how does one compensate for the change in confidnetiality and privacy aspects of the transfer mallory: we keep saying content authors; we actually mean publishers. that would be more accurate. we should also think more about goals for publishers. 'power imbalances' not the only issue for publishers; also monetization. MT: one thing missing is one clear articilation of he constraints people running this should operate in order to maintain guaratnees. agree with dkg. we are setting a new bar that require meeting a brand new set of requirements. that relates to things that mnot, jeffrey havem mentioned. along with personalisation. we should capture these and do an anaylsis to ensure that we can get this right. Another point: safe web app installtion is not a goal I am interested in puruing. There's a lot wrapped up in this. Could we solve AMP and constrained backhaul only? Peon: i don't want to be sued for being here because no one put a license on it. we should consider that here. ben schwarz: i agree with MT. 'out of scope for how browsers load format' -- no, we should list constraints. this could actually be a victory for privacy over HTTPs e.g. if servers push bundles this may have better privacy properties. felix handt: one of the things that satands out to me is something not included in the scope. discovery mechanism has been punted, many descriptions include only manual user discovery sean turner: charter review - items out of scope - no part of current draft has no presumption of making it through the WG process. peon: i don't understand why private stuff is out of scope? could increase security in some cases jyasskin: you need to protect private information peon: why not say that? --0000000000002402330597d3f193 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you all for your professional contributions to = the BoF yesterday where the consensus was that the BoF attendees did recomm= end the formation of a group using a charter derived from the comments pres= ented in the room and to further refined on this list.

= At the BoF the group committed to further=C2=A0work on the charter as the I= ESG decides what to do with the outcome of the BoF.

The = document. in view-only now, that we annotated with comments during the sess= ion is available here for your reference

The specific comments from the -00 revision of the minutes = during the charter discussion portion of the meeting are also included inli= ne here for your reference while you do your work.


Charter Review and Discussion
s= ean turner (opens google doc): now it's time for some group editing. [s= tarts reading the charter draft aloud]

MT: it is not true that we ca= nnot secure web apps over constrained edge channels.
mnot: last sentence= of first paragraph will be read as "a bundle is required for performa= nce", which is not true and recommend deleting it
bishop: "the= previous attempt to solve the problem was not deployed" please explai= n why
jyasskin: answering martin, browsers require secure context and yo= u don'tget that with files
[to mark] there is a webpack program that= is super-heavily used; you have to bundle to get good performance
rpeon= : bounced the WPACK idea of two folks that said this is not completely craz= y. mention of H2 server push and it is pertinent to consider that
mnot: = solved by changing HTTP/2 to HTTP/2 server push?
trammell: we're wor= dsmithing the background section
ben schwarz: can we not refer to a spec= ific thing in Cuba (el paquete semanal)
trammell: can I comment on somet= hing you haven't read yet
sean: no
mnot: was web pack sufficientl= y defined, is a =C2=A0liason required
trammell: [to aspects related to c= ryptography/security]I undesrtand where this came from and it gives me anxi= ety
ted: this is not granular enough. must talk about handling of items = in bundle as well.
trammell: use the headings in the Jeffrey's slide= s
peon: be more specific about security and privacy properties.
bisho= p: don't drop a third example, just don't refer directly to a Cuban= instance
mcmanus: we should move to things out of scope
dkg: the pro= perties that TLS 1.3 provides goes away if someone else delivers the datamcmanus: are you suggesting a bar that the wg would have to meet?
dkg:= how does one compensate for the change in confidnetiality and privacy aspe= cts of the transfer
mallory: we keep saying content authors; we actually= mean publishers. that would be more accurate. we should also think more ab= out goals for publishers. 'power imbalances' not the only issue for= publishers; also monetization.
MT: one thing missing is one clear artic= ilation of he constraints people running this should operate in order to ma= intain guaratnees. agree with dkg. we are setting a new bar that require me= eting a brand new set of requirements. that relates to things that mnot, je= ffrey havem mentioned. along with personalisation. we should capture these = and do an anaylsis to ensure that we can get this right. Another point: saf= e web app installtion is not a goal I am interested in puruing. There's= a lot wrapped up in this. Could we solve AMP and constrained backhaul only= ?
Peon: i don't want to be sued for being here because no one put a = license on it. we should consider that here.
ben schwarz: i agree with M= T. 'out of scope for how browsers load format' -- no, we should lis= t constraints. this could actually be a victory for privacy over HTTPs e.g.= if servers push bundles this may have better privacy properties.
felix = handt: one of the things that satands out to me is something not included i= n the scope. discovery mechanism has been punted, many descriptions include= only manual user discovery
sean turner: charter review - items out of s= cope - no part of current draft has no presumption of making it through the= WG process.
peon: i don't understand why private stuff is out of sc= ope? could increase security in some cases
jyasskin: you need to protect= private information
peon: why not say that?
--0000000000002402330597d3f193--