From nobody Mon Aug 5 10:50:02 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 CFCA01202A6 for ; Mon, 5 Aug 2019 10:50:00 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 eqN86pH8MST0 for ; Mon, 5 Aug 2019 10:49:58 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 66ACD1202ED for ; Mon, 5 Aug 2019 10:49:48 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id v24so80154822ljg.13 for ; Mon, 05 Aug 2019 10:49:48 -0700 (PDT) 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=DiLYLbCLbeSkrEX6vUPto6+2x+O1cAMnyBthX2KuSM0=; b=KHAqaESlJ2EzlmJsL+dqCcPiOaR7kkBYkf076iunvBL30gDRjjTDHamFuJJNQ2h7by czT0B+SKoki7B39E+gTEVtHBE9pSdb5Z9Pa6XtkCOQri2NNjK86elEifkGDeDs7mFpI9 xG6sjkflStHAaDeqASmOI6KXChsz9wDnW2yC7A//t0D1gSxXgY1kz5PjZCcJ62HepZwX 9hBMIM368LvNEH4wHJgroEs5Avchv/qjk/HX8y+db0gMTO8jj0YxiuhDy0BifezcmjMW Tkw4IwFJ+oOjpKAiDRrt9VCi7wHt6YYzJco/2lu5yAdEZ6KpIDpea4B+y+WYykn0hUT3 CZjQ== 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=DiLYLbCLbeSkrEX6vUPto6+2x+O1cAMnyBthX2KuSM0=; b=rLXAdBuBfRhX8RY2hKZA9wrakFi+aEqY5ZvQvK9eXD+2XiqV1Tq0WF/fUval/j3zt3 YF1Kl93O6Sajkycwn0Q92P76zyU7Q+Z5O67NKbQIc8cMfFoCeu//wVOdCHx3RgEoHhwE KEC8PCpYT3sp+y+udES+qAwmgZBOrrWP2nhK1asPWo0HMf1qk5hGI5FbY73uZsitQH0g n1hLDKGVk0nTQDBAF59TmkRqCnFMRnRM8iNSVjftQ55z+b2Rfv1nfgI0m/n6lrDZcIXu UQpfqkvyBRnKFd8kqPe+EtS4TwwJqtTcYsegHvRA6acsAxwfk8MzJE13MkdaTrgUaJtL wGWw== X-Gm-Message-State: APjAAAWA9UbLHzpolkFih34epNu6zX25dxAZGswvlkWgXu63CSvdEupy OsKeCLpeXZrMpFvHh6wOFzXFk4kNLcpBI1WqOj6k42LRtnEBGQ== X-Google-Smtp-Source: APXvYqxvLZuq9V+Mun4FynQG3KxHaEJ3KeS6qxoAjnwuKO3pycVy8sd9bnme2H2HW7L1XyZTogQpD0JsQtb75atotw0= X-Received: by 2002:a2e:8583:: with SMTP id b3mr43339306lji.171.1565027385559; Mon, 05 Aug 2019 10:49:45 -0700 (PDT) MIME-Version: 1.0 From: Jeffrey Yasskin Date: Mon, 5 Aug 2019 10:49:34 -0700 Message-ID: To: wpack@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Wpack] Problem statement and scope for BoF X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 17:50:01 -0000 I've drafted an initial problem statement and scope for the WPACK working group we're hoping to create at a BoF at IETF106 in Singapore. I've pasted it below, and you can suggest changes at https://bit.ly/wpack-draft-charter. I intend to draft a charter once I have some indication that the group here likes the scope I'm proposing. Thanks, Jeffrey Problem ======= There are large populations of users who have trouble making direct connections to HTTPS origin servers over the public internet. For example: * 55% of internet users live in countries where political, social, or religious content was blocked online. (https://freedomhouse.org/sites/default/files/FOTN_2018_Final%20Booklet_11_1_2018.pdf). * Other users run out of paid-for data in their mobile plan part-way through a month, or aggressively disable mobile data to make sure it's not wasted. * Others use satellite connections with high latency and packet loss. Anecdotally, see https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites-made-them-less-accessible/. These users currently have to, at best, tell their browsers to pre-fetch sites when they have a cheap real-time connection available or wait until they find such a connection, and at worst, can't browse the content at all. Even users with highly-available internet connections want to be able to read and interact with web pages as quickly as possible after clicking a link. Needing to make extra connections in the critical path, and having multiple connections competing for bandwidth without the ability to prioritize, interfere with that goal. All of these users deserve to know whether the content they're reading or application they're running actually comes from the origin it claims, and the publishers of those origins value their users being able to verify that the content is authentic. Both groups also value the users' ability to store data within websites and web applications (e.g. preferences and content they've created) and have it available the next time they load the same URL. Scope ===== 1. Define a way to package the public portion of one or more websites or web apps into one or more files that can be distributed and used without a direct connection to the origin server. 2. Define a way to sign these packages such that the result gives the recipient confidence in the integrity and authenticity of what they received. This work will ensure that a client loading a Web Package signed using the initial specification has security and privacy properties that are at least as good as a transferring the contained resources over HTTPS+TLS1.3 from the publishers' origin server(s) except that: a. Packages do not guarantee confidentiality, but if the channel that transfers the package provides confidentiality guarantees, packages at most compromise that by revealing information to the original origin server of the resources in the package and by making a TLS1.3-or-later private connection to that origin server. b. Packages only guarantee their contents were vouched by the origin servers' keys within the life of the signature, not during the life of the connection(s) that transferred them. c. Packages do not provide any of the security "guarantees" of the DNS system. d. A package generated for one client can be shared to other clients. e. TBD: Are the above sufficient? Can/should we give the WG permission to change this list? 3. Optionally define a way for clients to check that an origin server still vouches for its package in real time. 4. Define a way for an end-user to package their view of a site in order to show a peer what they saw. This could just be an update of RFC2557 (MHTML) but could instead be an un-signed variant of the same format as above. This kind of package will not guarantee integrity or authenticity from the origin server, but might from the end-user who packaged the site. 5. Define the resulting security and privacy model and compare it to the status quo security and privacy model of HTTPS. Search for places the existing web platform depends on the fact that HTTPS provides transport security and describe how those have to change or not given Packaging's addition of object security. This may involve working with W3C groups like WebAppSec and PING. 6. Formats that this group defines should be usable efficiently: a. When individual contained resources are either small (~10s of bytes) or large (~GB), b. When the total number of contained resources is either small (1) or large (thousands for the initial format with enough extensibility for an update to expand it to millions or billions), c. When the total size of all contained resources is either small (~KB) or large (~TB (matching El Paquete Semanal in Cuba) initially, with enough extensibility for an update to expand it to EB), and d. When the format is either streamed to the client or loaded from a slow but random-access medium like an SD card. 7. Ensure that any formats or protocols this group defines can be migrated to better cryptography when their original cryptography is broken. 8. As long as it doesn't compromise or delay the above goals, try to: a. Support signed statements about the content beyond just assertions that it's the representation of a particular URL. For example, that it appears on a transparency log, that it passed a certain kind of static analysis, or that a particular real-world entity vouches for it. b. Address the threat model of a website whose frontend might be compromised after a user first uses the site. c. Support books being published in the format. d. Support long-lived archival storage. e. Optimize transport of large numbers of small same-origin resources. f. Allow the format to be used in self-extracting executables. g. Allow publishers to efficiently combine sub-packages from other publishers. Out of scope ------------ 1. DRM 2. 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. 3. Defining the details of how web browsers load the formats and interact with any protocols we define here. The W3C and/or WHATWG are more appropriate fora for that effort. 4. A way to automatically discover the URL for an accessible package that includes content for a blocked or expensive-to-access URL that the user wants to browse. From nobody Mon Aug 5 16:28: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 520561200E7 for ; Mon, 5 Aug 2019 16:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 AlDomXBrflMv for ; Mon, 5 Aug 2019 16:27:58 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 227F31200C1 for ; Mon, 5 Aug 2019 16:27:58 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x75NR8qE027439; Tue, 6 Aug 2019 00:27:56 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=OA4hkZFuTEAUNZMYtJ1JueQWWDFuzuml3mkTmXs2pnc=; b=lz2AEClRQrj/+3clx7khoD8c9czc5a4L2QBWw56km1ssEj8PqPJJLlk3UpXsjHWeReUg hESs02T25Wl3iljXPxknMk8XSXHfSe/OKsZgRFxnZG6S0toV6uq22VgMQf0vlqVgo4l4 icrHzCtQxTrhFUlf5ZRoL4T7nM93onT3Mov2/uidZrjOol4t2pyWmyc4N+a7rwx45DUL wz2fTkuA1UOk93SMxwg0bDIrcdUcB6xCnXZYGRu70MZZcs2HdnvoFiYvZTd94IITp2XX nyGlCrI16ln+k/nBQdSLn8B1KeLNDxFj5dRRqJ9IZGrfuQhM6FuJj2OD3cbx3JulmEZa PA== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2u51h7kac9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Aug 2019 00:27:56 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x75NI2se013251; Mon, 5 Aug 2019 19:27:55 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint3.akamai.com with ESMTP id 2u55m12tcp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 05 Aug 2019 19:27:55 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 19:27:47 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Mon, 5 Aug 2019 19:27:47 -0400 From: "Salz, Rich" To: Jeffrey Yasskin , "wpack@ietf.org" Thread-Topic: [Wpack] Problem statement and scope for BoF Thread-Index: AQHVS7Y5soTKl9Q6r0ibFluHsp3M6KbtM1uA Date: Mon, 5 Aug 2019 23:27:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.163] Content-Type: text/plain; charset="utf-8" Content-ID: <2D610F5534DFCB48851B63F03B8A4E40@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-05_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=770 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908050235 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-05_13:2019-07-31,2019-08-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 lowpriorityscore=0 impostorscore=0 mlxlogscore=740 spamscore=0 clxscore=1011 adultscore=0 phishscore=0 bulkscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908050237 Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 23:27:59 -0000 Q29tbWVudGluZyBvbmx5IG9uIHRoZSAicHJvYmxlbSIgcGFydCBvZiB5b3VyIHBvc3Q7IEkgcmVz ZXJ2ZSB0aGUgcmlnaHQgdG8gY29tbWVudCBvbiBvdGhlciBwYXJ0cyBsYXRlciA6KQ0KDQpJIGFt IHN1cnByaXNlZCB0aGF0IHNlYXJjaCBjYXJvdXNlbCBhbmQgQU1QIGlzbid0IG1lbnRpb25lZCwg YXMgZnJhbmtseSBpdCBpcyB0aGUgdXNlLWNhc2Ugd2l0aCB0aGUgbW9zdCBlY29ub21pYyBpbmNl bnRpdmUvaW1wYWN0LiBIb25lc3R5IGNvbXBlbHMgdXMgdG8gZXhwbGljaXRseSBtZW50aW9uIGl0 LCBwbGFpbmx5LCBhbmQgZmlyc3QuDQoNCj4gICAgKiBPdGhlciB1c2VycyBydW4gb3V0IG9mIHBh aWQtZm9yIGRhdGEgaW4gdGhlaXIgbW9iaWxlIHBsYW4gcGFydC13YXkNCiAgICB0aHJvdWdoIGEg bW9udGgsIG9yIGFnZ3Jlc3NpdmVseSBkaXNhYmxlIG1vYmlsZSBkYXRhIHRvIG1ha2Ugc3VyZSBp dCdzDQogICAgbm90IHdhc3RlZC4NCiAgDQpXZSBoYXZlIHNlZW4gbm8gZXZpZGVuY2UgdGhhdCB0 aGlzIGlzIGRvbmUgYmVjYXVzZSBvZiBzdXJmaW5nLCBhcyBvcHBvc2VkIHRvIHRyYWNraW5nIG9y IG90aGVyIGFwcCBhY3Rpdml0eS4NCg0KIA0KDQo= From nobody Wed Aug 7 10:04:36 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 E9076120690 for ; Wed, 7 Aug 2019 10:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, URIBL_BLOCKED=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 x5uSWr9S2Ein for ; Wed, 7 Aug 2019 10:04:32 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 A98A51204AE for ; Wed, 7 Aug 2019 10:04:31 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id x25so86243750ljh.2 for ; Wed, 07 Aug 2019 10:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aKskPBBZFqgEZfWkrd8iirdKbZubX/AnPteIXskSgVo=; b=vEKo6LFr1PWAhtX9eG+0fTbGU+wD+5rEJpFmfDC0IsanQ8E89PblXwDcQ2wk+TfmN0 avpK6i09SZVw7XDYP4D7e3yv0ZKpPAbxEFROInSkTLXRf1HEEuQH9kLttey6opEwIb6q 5tJa/cPPSioZYsSoCDHzzYNGryozv+24jHlAaJj6lgWE+nGl+grfBYRDgXuEisgN3Nsq 9v+mFpR21ZTZg0aNJfnvoSAnUbPSpUi/iBn3Okq1d33ZWwbbOEW9xPkbwjo0fGaJyNrN Oee1/KtTK03Ie+ofgcS4zpDlJMzjctuO8dHIbsdp6nFPLRhXUhy5gMeRwLeSkqZDzUlL yGkA== 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=aKskPBBZFqgEZfWkrd8iirdKbZubX/AnPteIXskSgVo=; b=Vj2RCipVxli8UY8pwdiw8DnDFWaVLRALXG9wDiidVo6u39PiXi9OzcyvCIZGqUcK4F 1JrCcxcSw5BHWrR8HfJ3TKZKc+jM03l7Vr50tNhUkHTHa88Fu0wRgLYaZq7Z0ttZUg9R uCE6itgmUwdcbnwyWo2Lahrtb19xpnsVzeM+dB5VL9zsQqiQyKMkDi7fyRbhBOJy0we3 7FfuBH8l1Qvw7vzbL5DdTbrBHnUn8GXKnVGvgQ0SnuLXkG9uFpUGXURmnOLXQrb0y9z3 9IQPSqd3Uup/avSqnLGY06jv0aA4bojYKOH71mb7XmQH4hPEJsTCkmw60cnzsi5lcCoo 78Ag== X-Gm-Message-State: APjAAAWdT0qX4Hi3RFV814/t2uHbzrlWWLKivNRfVkW0n+IPP9IqOJpI l7XRbOhDlh+lWFc4VxlNpNuswCTkXzo4T8LoU2tMZzF7buQ= X-Google-Smtp-Source: APXvYqwkqgftQ0dBR573/BBIZ+pFvquMJQpVsm2Lp8w9ZUOZ7lHZeGARDLVlOiZck1ppoUzmZEpxLCbYLNTWN0aaOIQ= X-Received: by 2002:a2e:8e90:: with SMTP id z16mr5617552ljk.4.1565197469408; Wed, 07 Aug 2019 10:04:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Wed, 7 Aug 2019 10:04:16 -0700 Message-ID: To: "Salz, Rich" Cc: "wpack@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002b320d058f89ef4f" Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF 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, 07 Aug 2019 17:04:34 -0000 --0000000000002b320d058f89ef4f Content-Type: text/plain; charset="UTF-8" On Mon, Aug 5, 2019 at 4:28 PM Salz, Rich wrote: > Commenting only on the "problem" part of your post; I reserve the right to > comment on other parts later :) > > I am surprised that search carousel and AMP isn't mentioned, as frankly it > is the use-case with the most economic incentive/impact. Honesty compels us > to explicitly mention it, plainly, and first. > The AMP and Search Carousel use case is mentioned as "Even users with highly-available internet connections want to be able to read and interact with web pages as quickly as possible after clicking a link." The use case is broader than just one framework or piece of search result UI, so it seemed wrong to call out particular brands. Further, my impression of IETF charters is that they discuss and prioritize the goals of the IETF working group, not just the goals of the company employing the individuals who are proposing the WG. My impression is that the IETF sets a lower priority on fixing the AMP URL problem than improving access to the global internet, so I wrote the higher priority use case first. It's true that a lot of Google's investment in the problem is driven by trying to fix things around AMP, but I think it's fair to solve a problem for less-wealthy users by using funding from a wealthier client who can also benefit from the same solution. I'm happy to take changes here, but I need those changes to be designed to maximize the chance of chartering a working group. The ideal change comes with a statement along the lines of "I don't support chartering a WG with the current problem/scope/charter, but I would support it after this change." Rich, judging from your ESCAPE submission, you don't want the IETF to do this work at all, so I worry that if I take your suggestions, it'll make the IETF less likely to create the WG. If I've misread your post, and you actually think the IETF is enthusiastic to prioritize AMP first, let me know. > > * Other users run out of paid-for data in their mobile plan part-way > through a month, or aggressively disable mobile data to make sure it's > not wasted. > > We have seen no evidence that this is done because of surfing, as opposed > to tracking or other app activity. > I agree. The inference I'm going for here is that, if users have turned off or run out of their data, even because of native-app misbehavior, they can't then browse to and install a web app. I'm having trouble coming up with wording that would make that clearer without being too wordy. Any ideas? Jeffrey --0000000000002b320d058f89ef4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 5, 2019 at 4:28 PM Salz, Rich= <rsalz@akamai.com= > wrote:
Commenting only on the "problem" part = of your post; I reserve the right to comment on other parts later :)

I am surprised that search carousel and AMP isn't mentioned, as frankly= it is the use-case with the most economic incentive/impact. Honesty compel= s us to explicitly mention it, plainly, and first.
The AMP and Search Carousel use case is mentioned as "Even= users with highly-available internet connections want to be able to read a= nd interact with web pages as quickly as possible after clicking a link.&qu= ot; The use case is broader than just one framework or piece of search resu= lt UI, so it seemed wrong to call out particular brands.

Further, my impression of IETF charters is that they discuss and pri= oritize the goals of the IETF working group, not just the goals of the comp= any employing the individuals who are proposing the WG. My impression is th= at the IETF sets a lower priority on fixing the AMP URL problem than improv= ing access to the global internet, so I wrote the higher priority use case = first.

It's true that a lot of Google's in= vestment in the problem is driven by trying to fix things around AMP, but I= think it's fair to solve a problem for less-wealthy users by using fun= ding from a wealthier client who can also benefit from the same solution.

I'm happy to take changes here, but I need thos= e changes to be designed to maximize the chance of chartering a working gro= up. The ideal change comes with a statement along the lines of "I don&= #39;t support chartering a WG with the current problem/scope/charter, but I= would support it after this change." Rich, judging from your ESCAPE s= ubmission, you don't want the IETF to do this work at all, so I worry t= hat if I take your suggestions, it'll make the IETF less likely to crea= te the WG. If I've misread your post, and you actually think the IETF i= s enthusiastic to prioritize AMP first, let me know.
=C2=A0
=
>=C2=A0 =C2=A0 * Other users run out of paid-for data in their mobile pl= an part-way
=C2=A0 =C2=A0 through a month, or aggressively disable mobile data to make = sure it's
=C2=A0 =C2=A0 not wasted.

We have seen no evidence that this is done because of surfing, as opposed t= o tracking or other app activity.

I agr= ee. The inference I'm going for here is that, if users have turned off = or run out of their data, even because of native-app misbehavior, they can&= #39;t then browse to and install a web app. I'm having trouble coming u= p with wording that would make that clearer without being too wordy. Any id= eas?

Jeffrey
--0000000000002b320d058f89ef4f-- From nobody Wed Aug 7 10:12: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 5A586120192 for ; Wed, 7 Aug 2019 10:12:30 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 MAEGpxjDjS3n for ; Wed, 7 Aug 2019 10:12:28 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 5ECAC120232 for ; Wed, 7 Aug 2019 10:12:28 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x77Gw2aF015786; Wed, 7 Aug 2019 18:12:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=2IOwspE/zQAzHgblP3SuIKKZsFlSfgTnOJqNNh2abKA=; b=J8PXxP9miL+w763ibIGN4KuH739FQFiixpbhYOszSeZVnxmjNmcM8NCqYNa/8Cb9vYeD naRyf/3KlMGqYkXJN5kRNvx/SkQdHivRRVO4wpCdjPR2/iKfkhIWAywVIEUWsccTaPK5 JxfDe3Y/euALYbeVgQGGJJ+dKd7m+QgTBTT048rPymRye9+TvFidJ0J8jR4Ukf3had8w XT5NWtVqM14yt5fxVv+JAwsGHIspxL/X/f7r+Mt9AXkK6NZASvnwecpNFhS4jlDoXY1t IqVaLjkTVE8QlPLlu9T9GoGrHkRpZY+u86eZ9BzHC+c7Lx9KmOKLip6ClQsECBZBdoSv fQ== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2u51wv1tqe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Aug 2019 18:12:25 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x77H2Yn4019430; Wed, 7 Aug 2019 13:12:25 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2u55m19w7p-1; Wed, 07 Aug 2019 13:12:24 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 5541B815F8; Wed, 7 Aug 2019 17:12:21 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1hvPU3-0005lK-R8; Wed, 07 Aug 2019 12:12:19 -0500 Date: Wed, 7 Aug 2019 12:12:19 -0500 From: Benjamin Kaduk To: Jeffrey Yasskin Cc: "Salz, Rich" , "wpack@ietf.org" Message-ID: <20190807171218.GB19909@akamai.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-07_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=614 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908070166 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-07_04:2019-08-07,2019-08-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 bulkscore=0 mlxlogscore=600 priorityscore=1501 adultscore=0 lowpriorityscore=0 mlxscore=0 spamscore=0 phishscore=0 clxscore=1011 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908070166 Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF 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, 07 Aug 2019 17:12:30 -0000 On Wed, Aug 07, 2019 at 10:04:16AM -0700, Jeffrey Yasskin wrote: > On Mon, Aug 5, 2019 at 4:28 PM Salz, Rich wrote: > > > Commenting only on the "problem" part of your post; I reserve the right to > > comment on other parts later :) > > > > I am surprised that search carousel and AMP isn't mentioned, as frankly it > > is the use-case with the most economic incentive/impact. Honesty compels us > > to explicitly mention it, plainly, and first. > > > > The AMP and Search Carousel use case is mentioned as "Even users with > highly-available internet connections want to be able to read and interact > with web pages as quickly as possible after clicking a link." The use case > is broader than just one framework or piece of search result UI, so it > seemed wrong to call out particular brands. > > Further, my impression of IETF charters is that they discuss and prioritize > the goals of the IETF working group, not just the goals of the company > employing the individuals who are proposing the WG. My impression is that > the IETF sets a lower priority on fixing the AMP URL problem than improving > access to the global internet, so I wrote the higher priority use case > first. > > It's true that a lot of Google's investment in the problem is driven by > trying to fix things around AMP, but I think it's fair to solve a problem > for less-wealthy users by using funding from a wealthier client who can > also benefit from the same solution. > > I'm happy to take changes here, but I need those changes to be designed to > maximize the chance of chartering a working group. The ideal change comes > with a statement along the lines of "I don't support chartering a WG with > the current problem/scope/charter, but I would support it after this > change." Rich, judging from your ESCAPE submission, you don't want the IETF > to do this work at all, so I worry that if I take your suggestions, it'll > make the IETF less likely to create the WG. If I've misread your post, and > you actually think the IETF is enthusiastic to prioritize AMP first, let me > know. Well, given the recent breadth of discussion around expanding the Internet threat model, there's also been a bit of introspection about the way we think about the work we do in general. So that we are not just going to consider what the stated goals are (and whether they can be achieved), but what the side effects of doing that work would be, and whether there are other (potentially harmful) consequences of building a given technology. The IAB has explicitly indicated that the risk of consolidation into a small number of service providers is something they are concerned about, and so if one should expect them (and, presumably, the IESG as well) to take that risk into account when considering chartering new work. Having an honest discussion of what the possible and likely side effects of a given technology could be seems to be a generally helpful thing for the IAB and IESG in their consideration of proposed ne work, and I for one would welcome such a discussion here. -Ben From nobody Wed Aug 7 10:14:41 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 64B5A1206F6 for ; Wed, 7 Aug 2019 10:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 d2vPdA1zgO7c for ; Wed, 7 Aug 2019 10:14:32 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 A71291206E7 for ; Wed, 7 Aug 2019 10:14:18 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x77GwTge018589; Wed, 7 Aug 2019 18:14:18 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=83F9bNOxi9DzY9cQP/dTvVdjOwbYhJbEKxckw7DY4BU=; b=cAMcLfGB4kPhoGeTTTJO4HKwdD4LgDoF3P6QpYwxiQWaQk2zKR9wmWOzbYdS79oYNcMh fD89nkJIw3KbnYRd1stqocQJpX3hTskXyVsFzFN//TvswUAUywvWNp7nemQWAyFlnZKV SmJlSCsZsq9zb2Rbgo6h5tzFNEv6RJmbZTZScPtvcqQYLGrqBdSIMrTGEYHUME2UtslW qxP8uRaW6or9PqvtZ3bTD5T2SVDCoepqq47wnPctEJxqZnB9fgXj5FtS4L286wLhtqOs 6gyGKdeyTGQGUcm6lQypp9RcA3M+iDhq78kJSWuZFyhhz2KVeGhgnUm6qsWAJhdWwl0F cg== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2u51t4mbq9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Aug 2019 18:14:18 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x77H2Sbw021337; Wed, 7 Aug 2019 10:14:16 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint5.akamai.com with ESMTP id 2u5888fdu4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 07 Aug 2019 10:14:16 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 13:14:16 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Wed, 7 Aug 2019 13:14:16 -0400 From: "Salz, Rich" To: Jeffrey Yasskin , "wpack@ietf.org" Thread-Topic: [Wpack] Problem statement and scope for BoF Thread-Index: AQHVS7Y5soTKl9Q6r0ibFluHsp3M6Kbv76eA Date: Wed, 7 Aug 2019 17:14:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.97] Content-Type: text/plain; charset="utf-8" Content-ID: <858D4E825031D84AB486C168D14752D0@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-07_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908070166 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-07_04:2019-08-07,2019-08-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 priorityscore=1501 mlxscore=0 mlxlogscore=999 spamscore=0 clxscore=1015 adultscore=0 phishscore=0 malwarescore=0 bulkscore=0 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908070166 Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF 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, 07 Aug 2019 17:14:39 -0000 PiAgICAqIE90aGVyIHVzZXJzIHJ1biBvdXQgb2YgcGFpZC1mb3IgZGF0YSBpbiB0aGVpciBtb2Jp bGUgcGxhbiBwYXJ0LXdheQ0KICAgIHRocm91Z2ggYSBtb250aCwgb3IgYWdncmVzc2l2ZWx5IGRp c2FibGUgbW9iaWxlIGRhdGEgdG8gbWFrZSBzdXJlIGl0J3MNCiAgICBub3Qgd2FzdGVkLg0KICAN ClN0cmlrZSB0aGlzIGl0ZW07IHRoZXJlIGlzICp6ZXJvKiBkYXRhIHRvIGluZGljYXRlIHRoYXQg aXQgaXMgYmVjYXVzZSBvZiB1c2VycyAoaW5hZHZlcnRlbnRseSkgbG9hZGluZyB3ZWIgcGFnZXMs IGFzIG9wcG9zZWQgdG8gb3RoZXIgcmVhc29ucywgc3VjaCBhcyBwdXNoIG5vdGlmaWNhdGlvbnMs IGdlby10cmFja2luZywgYW5kIHNvIG9uLg0KICAgIA0KPiAgICBUaGVzZSB1c2VycyBjdXJyZW50 bHkgaGF2ZSB0bywgYXQgYmVzdCwgdGVsbCB0aGVpciBicm93c2VycyB0bw0KICAgIHByZS1mZXRj aCBzaXRlcyB3aGVuIHRoZXkgaGF2ZSBhIGNoZWFwIHJlYWwtdGltZSBjb25uZWN0aW9uIGF2YWls YWJsZQ0KICAgIG9yIHdhaXQgdW50aWwgdGhleSBmaW5kIHN1Y2ggYSBjb25uZWN0aW9uLCBhbmQg YXQgd29yc3QsIGNhbid0IGJyb3dzZQ0KICAgIHRoZSBjb250ZW50IGF0IGFsbC4NCiAgDQpZZXMs IHRoaXMgY2hhcmFjdGVyaXplcyB0aGUgcHJldmlvdXMgaXRlbXMuICBIT1dFVkVSLCBJIHN0cm9u Z2x5IHN1Z2dlc3QgdGhhdCB3ZSBuZWVkIGEgbmV3IGZpcnN0IGl0ZW0sIGFuZCB0aGlzIHBhcmFn cmFwaCB0aGVuIGJlY29tZXMgZGlsdXRlZC4gIFNvbWUgcmVzdHJ1Y3R1cmluZyB3aWxsIGJlIG5l Y2Vzc2FyeS4NCiAgDQo+ICAgIEV2ZW4gdXNlcnMgd2l0aCBoaWdobHktYXZhaWxhYmxlIGludGVy bmV0IGNvbm5lY3Rpb25zIHdhbnQgdG8gYmUgYWJsZQ0KICAgIHRvIHJlYWQgYW5kIGludGVyYWN0 IHdpdGggd2ViIHBhZ2VzIGFzIHF1aWNrbHkgYXMgcG9zc2libGUgYWZ0ZXINCiAgICBjbGlja2lu ZyBhIGxpbmsuIE5lZWRpbmcgdG8gbWFrZSBleHRyYSBjb25uZWN0aW9ucyBpbiB0aGUgY3JpdGlj YWwNCiAgICBwYXRoLCBhbmQgaGF2aW5nIG11bHRpcGxlIGNvbm5lY3Rpb25zIGNvbXBldGluZyBm b3IgYmFuZHdpZHRoIHdpdGhvdXQNCiAgICB0aGUgYWJpbGl0eSB0byBwcmlvcml0aXplLCBpbnRl cmZlcmUgd2l0aCB0aGF0IGdvYWwuDQogIA0KSSBhbSBub3Qgc3VyZSBJIGFncmVlIHdpdGggdGhp cy4gIFRoZXJlIGlzIGEgbGFyZ2UgYm9keSBvZiB1c2VyIGV4cGVyaWVuY2Ugc3R1ZGllcyB0aGF0 IHNob3cgaG93IGxvbmcgYSBkZWxheSBjYW4gYmUgYW5kIHplcm8gaXNuJ3QgaXQuIDopDQoNCk5F VyBGSVJTVCBJVEVNLiAgSSBiZWxpZXZlIHRoZSBmb2xsb3dpbmcgY2FwdHVyZXMgdGhlIHJlYWwg ZHJpdmVyIGJlaGluZCB0aGlzIHdvcmsuIFNvIG11Y2ggc28gdGhhdCB0aGlzIHNob3VsZCBiZSB0 aGUgZmlyc3QgbGlzdGVkIG1vdGl2YXRvciBvZiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQuIFdoaWxl IHRoZSBvdGhlciB1c2UtY2FzZXMgYXJlIGltcG9ydGFudCwgSSBhbSBsZXNzIHNhbmd1aW5lIC0t IG9yIHBlcmhhcHMganVzdCBtb3JlIGN5bmljYWwgLS0gdGhhdCB0aG9zZSB0aGluZ3Mgd2lsbCBl dmVyIGJlIGFkZHJlc3NlZC4gIFRoZSBtYWluIGRyaXZlciBoYXMgYmlsbGlvbnMgb2YgZG9sbGFy cyBiZWhpbmQgaXQgYWZ0ZXIgYWxsLg0KDQoqIFRoaXJkLXBhcnR5IGFnZ3JlZ2F0b3JzLCBzdWNo IGFzIHNvY2lhbCBtZWRpYSBhbmQgc2VhcmNoIGVuZ2luZXMsIHdhbnQgdG8gcHVzaCBleHRlcm5h bCBjb250ZW50IHRvIHRoZSB1c2VyIHdoaWxlIHRoZSBwYWdlIGlzIGJlaW5nIGxvYWRlZCBhbmQv b3IgZGlzcGxheWVkLiBUaGlzIGVuYWJsZXMgcHJldmlld3MsIG9yIHRodW1ibmFpbHMsIGV0Yy4s IHRvIGJlIGRpc3BsYXllZCB3aXRob3V0IHRoZSB1c2VyIGNvbW1pdHRpbmcgdG8gc2VlaW5nIHRo ZSBmdWxsIGNvbnRlbnQgKGFuZCB0aGVyZWZvcmUgd2l0aG91dCB0aGUgb3JpZ2luIGdldHRpbmcg bm90aWZpY2F0aW9uKS4gQWxsIHRocmVlIHBhcnRpZXMgLS0gdGhlIHVzZXIsIHRoZSBvcmlnaW4s IGFuZCB0aGUgYWdncmVnYXRvciAtLSB3YW50IHRoaXMgY29udGVudCB0byBiZSBjcnlwdG9ncmFw aGljYWxseSBzZWN1cmUgYW5kIHRhbXBlci1ldmlkZW50Lg0KDQpJIHByZWZlciB0byBoYXZlIGRp c2N1c3Npb25zIG9uIHRoZSBtYWlsaW5nIGxpc3QgZm9yIGdyZWF0ZXIgdmlzaWJpbGl0eSwgYXJj aGl2aW5nLCBhbmQgYmVjYXVzZSBpdCdzIG1vcmUgSUVURi1saWtlLg0KDQoNCg== From nobody Wed Aug 7 10:19:56 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 27008120742 for ; Wed, 7 Aug 2019 10:19:51 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 V1MwTUZ3wlmT for ; Wed, 7 Aug 2019 10:19:46 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 4DE65120689 for ; Wed, 7 Aug 2019 10:19:39 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x77GwLiV013708; Wed, 7 Aug 2019 18:19:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=u3bek7r88I7CDbwHiTBt7glE++7UkiPE8uFGWbIOXo4=; b=YZW/E9ep9p8oVclIeWwAKsp69srTWliEjsGGpOwljp0jlZZ1eiqdD2oxkfUodsY1z5sY ayOAf8ZH5ZN2Thz0il5/hMjN757PX+5u4Po6Fz1VSHd+AO/Q2bWmu+dEfw0HHvcgbB8y o+9DAJ8U9HVRZnF/nYfAx42gkipEhJ7+Y5iqIZTirJkoxNWH4pBAekxb+dvT1oO/yFzw 06/5Kaps3qSxCsMc+5P8QisWKLjYoMUzj5LWpPb6ReMe5TYCApZCtjpbKBNZA8RUvVqt 0PJoXfGFY6Yolup7UWh350TasV4tydKisyYLMTqG1301MMDuMVElQ7P3wRa31XIuFqcX rw== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2u52p8jkn4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Aug 2019 18:19:37 +0100 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x77H2STL013554; Wed, 7 Aug 2019 13:19:36 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint8.akamai.com with ESMTP id 2u55kvd04q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 07 Aug 2019 13:19:36 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 13:19:35 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Wed, 7 Aug 2019 13:19:35 -0400 From: "Salz, Rich" To: Jeffrey Yasskin CC: "wpack@ietf.org" Thread-Topic: [Wpack] Problem statement and scope for BoF Thread-Index: AQHVS7Y5soTKl9Q6r0ibFluHsp3M6KbtM1uAgAL8kAD//8E4AA== Date: Wed, 7 Aug 2019 17:19:34 +0000 Message-ID: <3ED3A38E-CF3A-4468-B3D0-6082985D71B7@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.97] Content-Type: multipart/alternative; boundary="_000_3ED3A38ECF3A4468B3D06082985D71B7akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-07_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=867 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908070166 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-07_04:2019-08-07,2019-08-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 priorityscore=1501 adultscore=0 lowpriorityscore=0 mlxscore=0 spamscore=0 mlxlogscore=840 malwarescore=0 impostorscore=0 clxscore=1011 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908070166 Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF 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, 07 Aug 2019 17:19:54 -0000 --_000_3ED3A38ECF3A4468B3D06082985D71B7akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PkknbSBoYXBweSB0byB0YWtlIGNoYW5nZXMgaGVyZSwgYnV0IEkgbmVlZCB0aG9zZSBjaGFuZ2Vz IHRvIGJlIGRlc2lnbmVkIHRvIG1heGltaXplIHRoZSBjaGFuY2Ugb2YgY2hhcnRlcmluZyBhIHdv cmtpbmcgZ3JvdXAuIFRoZSBpZGVhbCBjaGFuZ2UgY29tZXMgd2l0aCBhIHN0YXRlbWVudCBhbG9u ZyB0aGUgbGluZXMgb2YgIkkgZG9uJ3Qgc3VwcG9ydCBjaGFydGVyaW5nIGEgV0cgd2l0aCB0aGUg Y3VycmVudCBwcm9ibGVtL3Njb3BlL2NoYXJ0ZXIsIGJ1dCBJIHdvdWxkIHN1cHBvcnQgaXQgYWZ0 ZXIgdGhpcyBjaGFuZ2UuIiBSaWNoLCBqdWRnaW5nIGZyb20geW91ciBFU0NBUEUgc3VibWlzc2lv biwgeW91IGRvbid0IHdhbnQgdGhlIElFVEYgdG8gZG8gdGhpcyB3b3JrIGF0IGFsbCwgc28gSSB3 b3JyeSB0aGF0IGlmIEkgdGFrZSB5b3VyIHN1Z2dlc3Rpb25zLCBpdCdsbCBtYWtlIHRoZSBJRVRG IGxlc3MgbGlrZWx5IHRvIGNyZWF0ZSB0aGUgV0cuIElmIEkndmUgbWlzcmVhZCB5b3VyIHBvc3Qs IGFuZCB5b3UgYWN0dWFsbHkgdGhpbmsgdGhlIElFVEYgaXMgZW50aHVzaWFzdGljIHRvIHByaW9y aXRpemUgQU1QIGZpcnN0LCBsZXQgbWUga25vdy4NCg0KU28gSSBvbmx5IGdldCBvbmUgY2hhbmNl IHRvIG1ha2Ugc3VnZ2VzdGlvbnMgb3IgY29tbWVudHM/IEFuZCBpZiwgYWZ0ZXIgdGhhdCBvbmUg Y2hhbmdlIEnigJltIG5vdCB3aWxsaW5nIHRvIGNvbW1pdCB0byBzdXBwb3J0aW5nIHlvdXIgcHJv amVjdCB5b3Ugd2lsbCBpZ25vcmUgbWU/DQoNClN1cmVseSwgeW91IGRvbuKAmXQgbWVhbiB0aGF0 LCBhbmQgSSBhbSBqdXN0IG1pcy1yZWFkaW5nIHdoYXQgeW91IHdyb3RlLCBhbmQgSSBsb29rIGZv cndhcmQgdG8gc2VlaW5nIHlvdXIgY29ycmVjdGlvbi4NCg0K --_000_3ED3A38ECF3A4468B3D06082985D71B7akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZndDtJJ20gaGFwcHkgdG8gdGFrZSBjaGFuZ2VzIGhlcmUsIGJ1dCBJIG5lZWQg dGhvc2UgY2hhbmdlcyB0byBiZSBkZXNpZ25lZCB0byBtYXhpbWl6ZSB0aGUgY2hhbmNlIG9mIGNo YXJ0ZXJpbmcgYSB3b3JraW5nIGdyb3VwLiBUaGUgaWRlYWwgY2hhbmdlIGNvbWVzIHdpdGggYSBz dGF0ZW1lbnQgYWxvbmcgdGhlIGxpbmVzIG9mICZxdW90O0kgZG9uJ3Qgc3VwcG9ydCBjaGFydGVy aW5nIGEgV0cgd2l0aCB0aGUgY3VycmVudA0KIHByb2JsZW0vc2NvcGUvY2hhcnRlciwgYnV0IEkg d291bGQgc3VwcG9ydCBpdCBhZnRlciB0aGlzIGNoYW5nZS4mcXVvdDsgUmljaCwganVkZ2luZyBm cm9tIHlvdXIgRVNDQVBFIHN1Ym1pc3Npb24sIHlvdSBkb24ndCB3YW50IHRoZSBJRVRGIHRvIGRv IHRoaXMgd29yayBhdCBhbGwsIHNvIEkgd29ycnkgdGhhdCBpZiBJIHRha2UgeW91ciBzdWdnZXN0 aW9ucywgaXQnbGwgbWFrZSB0aGUgSUVURiBsZXNzIGxpa2VseSB0byBjcmVhdGUgdGhlIFdHLiBJ ZiBJJ3ZlDQogbWlzcmVhZCB5b3VyIHBvc3QsIGFuZCB5b3UgYWN0dWFsbHkgdGhpbmsgdGhlIElF VEYgaXMgZW50aHVzaWFzdGljIHRvIHByaW9yaXRpemUgQU1QIGZpcnN0LCBsZXQgbWUga25vdy48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIEkgb25seSBnZXQgb25lIGNoYW5jZSB0 byBtYWtlIHN1Z2dlc3Rpb25zIG9yIGNvbW1lbnRzPyBBbmQgaWYsIGFmdGVyIHRoYXQgb25lIGNo YW5nZSBJ4oCZbSBub3Qgd2lsbGluZyB0byBjb21taXQgdG8gc3VwcG9ydGluZyB5b3VyIHByb2pl Y3QgeW91IHdpbGwgaWdub3JlIG1lPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdXJlbHksIHlv dSBkb27igJl0IG1lYW4gdGhhdCwgYW5kIEkgYW0ganVzdCBtaXMtcmVhZGluZyB3aGF0IHlvdSB3 cm90ZSwgYW5kIEkgbG9vayBmb3J3YXJkIHRvIHNlZWluZyB5b3VyIGNvcnJlY3Rpb24uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3ED3A38ECF3A4468B3D06082985D71B7akamaicom_-- From nobody Wed Aug 7 11:21:07 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 56F3D1206C7 for ; Wed, 7 Aug 2019 11:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, URIBL_BLOCKED=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 6QRpwD_N1Th7 for ; Wed, 7 Aug 2019 11:21:02 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 B42A31206B4 for ; Wed, 7 Aug 2019 11:21:01 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id v18so86323303ljh.6 for ; Wed, 07 Aug 2019 11:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o2F+ZfjMPk6G8bnKiM7qudD1RBbsyj4p+hC99imMxAg=; b=c8EQy2cVXeTacMpRiIbbIgbE7iglunY/xqNg7aOaT9efwZqMlb7yQBP3h1WPmOsssw 4a+4GHQDjCfrOEn4r+qyzqYb62dhXfa7UQohoTS+/n2VRhI78bShnrRdTDn1UwnQquDx wjVwh88E1JBNKwToiXO1a+6m0VKU8PSTzELmMCUZ+yTiurmqcW0MyeQXdMYvhom9wKMW gdNXxi7b4WtLkcAYpKuDbSc/tv037+K2ckSft2Bl7AysuDeXQirzD5xKuKIa3tu0Qw1e reVAvhsu5AaB6Yz9QJxpXXJViIzGUrHujU4RFaL99VbAwxJekyXyeNK8av2CRs78ZpEl fbMQ== 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=o2F+ZfjMPk6G8bnKiM7qudD1RBbsyj4p+hC99imMxAg=; b=L1iS/o17fqQQvYIOvvQh8bxr32EqjxBDfNKq2EjPCsUTUcO9OoxX3T8p2gVLu3jTx0 V9hIE60I8s7xY6pBprKQKWokvwaI0f+pv79Ey1I0Huv4clE+IzqlCL+1Z84GzEz1+MSN O2+xgVEhmZv4RcQ2i5H+6a6Ej7wW46VsdDQnk2sUnYVhnWLvNfLKDhHFOk2WlXBsSXDb 9yATosbXr72Lx5mSRGAxi+Q5cEi3h+EfqAxZNYjsPK03l9sc2V5sqBLqt24t/GMNK0jA lt+DReH0xUDdHqlG6YnfLQjkoPPSaDQyO55YJirJFRlRAln4km4UlBeEnMYTY0WTAx+C 0hAw== X-Gm-Message-State: APjAAAWkaNF8ZoZCPqa6aekrHaJQiiBE0NueDi+8CSo/LqS3jMIzLtqj uZKZn/vNwOy8Md+IZlDeKDz3tQYcFpEicUdLqav9nw== X-Google-Smtp-Source: APXvYqxBVDpLAUHPATIyBiPNQfRJw2+0etGhn06Mu3On8o57NP+N6345A5kSJkS6J/ear+3DG5fnElIhxUfGKriEd5c= X-Received: by 2002:a2e:7c14:: with SMTP id x20mr3576230ljc.56.1565202059189; Wed, 07 Aug 2019 11:20:59 -0700 (PDT) MIME-Version: 1.0 References: <20190807171218.GB19909@akamai.com> In-Reply-To: <20190807171218.GB19909@akamai.com> From: Jeffrey Yasskin Date: Wed, 7 Aug 2019 11:20:46 -0700 Message-ID: To: Benjamin Kaduk , Martin Thomson Cc: "Salz, Rich" , "wpack@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bdd02d058f8b00bf" Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF 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, 07 Aug 2019 18:21:05 -0000 --000000000000bdd02d058f8b00bf Content-Type: text/plain; charset="UTF-8" On Wed, Aug 7, 2019 at 10:12 AM Benjamin Kaduk wrote: > On Wed, Aug 07, 2019 at 10:04:16AM -0700, Jeffrey Yasskin wrote: > > On Mon, Aug 5, 2019 at 4:28 PM Salz, Rich wrote: > > > > > Commenting only on the "problem" part of your post; I reserve the > right to > > > comment on other parts later :) > > > > > > I am surprised that search carousel and AMP isn't mentioned, as > frankly it > > > is the use-case with the most economic incentive/impact. Honesty > compels us > > > to explicitly mention it, plainly, and first. > > > > > > > The AMP and Search Carousel use case is mentioned as "Even users with > > highly-available internet connections want to be able to read and > interact > > with web pages as quickly as possible after clicking a link." The use > case > > is broader than just one framework or piece of search result UI, so it > > seemed wrong to call out particular brands. > > > > Further, my impression of IETF charters is that they discuss and > prioritize > > the goals of the IETF working group, not just the goals of the company > > employing the individuals who are proposing the WG. My impression is that > > the IETF sets a lower priority on fixing the AMP URL problem than > improving > > access to the global internet, so I wrote the higher priority use case > > first. > > > > It's true that a lot of Google's investment in the problem is driven by > > trying to fix things around AMP, but I think it's fair to solve a problem > > for less-wealthy users by using funding from a wealthier client who can > > also benefit from the same solution. > > > > I'm happy to take changes here, but I need those changes to be designed > to > > maximize the chance of chartering a working group. The ideal change comes > > with a statement along the lines of "I don't support chartering a WG with > > the current problem/scope/charter, but I would support it after this > > change." Rich, judging from your ESCAPE submission, you don't want the > IETF > > to do this work at all, so I worry that if I take your suggestions, it'll > > make the IETF less likely to create the WG. If I've misread your post, > and > > you actually think the IETF is enthusiastic to prioritize AMP first, let > me > > know. > > Well, given the recent breadth of discussion around expanding the > Internet threat model, there's also been a bit of introspection about > the way we think about the work we do in general. So that we are not > just going to consider what the stated goals are (and whether they can > be achieved), but what the side effects of doing that work would be, and > whether there are other (potentially harmful) consequences of building a > given technology. The IAB has explicitly indicated that the risk of > consolidation into a small number of service providers is something they > are concerned about, and so if one should expect them (and, presumably, > the IESG as well) to take that risk into account when considering > chartering new work. Having an honest discussion of what the possible > and likely side effects of a given technology could be seems to be a > generally helpful thing for the IAB and IESG in their consideration of > proposed ne work, and I for one would welcome such a discussion here. > > -Ben > That's a great point, and I'm adding a section for it to my document. However, I don't have very good content for that section. We had the ESCAPE workshop partly to try to find ways that Web Packaging might increase the risk of consolidation, and Martin is writing the report from there, but I didn't come away with any mechanisms that seem likely to have a big effect. Martin, do you have a good list of ways folks are worried that Packaging will centralize service providers? Ben, do you have any examples of charters that have incorporated this kind of discussion? I'd like to be able to copy the structure if possible. Thanks, Jeffrey --000000000000bdd02d058f8b00bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 7, 2019 at 10:12 AM Benjamin = Kaduk <bkaduk@akamai.com> wr= ote:
On Wed, Aug 07, 2019 at 10:04:16AM -0700, Jeffrey Yasskin w= rote:
> On Mon, Aug 5, 2019 at 4:28 PM Salz, Rich <rsalz@akamai.com> wrote:
>
> > Commenting only on the "problem" part of your post; I r= eserve the right to
> > comment on other parts later :)
> >
> > I am surprised that search carousel and AMP isn't mentioned, = as frankly it
> > is the use-case with the most economic incentive/impact. Honesty = compels us
> > to explicitly mention it, plainly, and first.
> >
>
> The AMP and Search Carousel use case is mentioned as "Even users = with
> highly-available internet connections want to be able to read and inte= ract
> with web pages as quickly as possible after clicking a link." The= use case
> is broader than just one framework or piece of search result UI, so it=
> seemed wrong to call out particular brands.
>
> Further, my impression of IETF charters is that they discuss and prior= itize
> the goals of the IETF working group, not just the goals of the company=
> employing the individuals who are proposing the WG. My impression is t= hat
> the IETF sets a lower priority on fixing the AMP URL problem than impr= oving
> access to the global internet, so I wrote the higher priority use case=
> first.
>
> It's true that a lot of Google's investment in the problem is = driven by
> trying to fix things around AMP, but I think it's fair to solve a = problem
> for less-wealthy users by using funding from a wealthier client who ca= n
> also benefit from the same solution.
>
> I'm happy to take changes here, but I need those changes to be des= igned to
> maximize the chance of chartering a working group. The ideal change co= mes
> with a statement along the lines of "I don't support charteri= ng a WG with
> the current problem/scope/charter, but I would support it after this > change." Rich, judging from your ESCAPE submission, you don't= want the IETF
> to do this work at all, so I worry that if I take your suggestions, it= 'll
> make the IETF less likely to create the WG. If I've misread your p= ost, and
> you actually think the IETF is enthusiastic to prioritize AMP first, l= et me
> know.

Well, given the recent breadth of discussion around expanding the
Internet threat model, there's also been a bit of introspection about the way we think about the work we do in general.=C2=A0 So that we are not<= br> just going to consider what the stated goals are (and whether they can
be achieved), but what the side effects of doing that work would be, and whether there are other (potentially harmful) consequences of building a given technology.=C2=A0 The IAB has explicitly indicated that the risk of consolidation into a small number of service providers is something they are concerned about, and so if one should expect them (and, presumably,
the IESG as well) to take that risk into account when considering
chartering new work.=C2=A0 Having an honest discussion of what the possible=
and likely side effects of a given technology could be seems to be a
generally helpful thing for the IAB and IESG in their consideration of
proposed ne work, and I for one would welcome such a discussion here.

-Ben

That's a great point, and I= 9;m adding a section for= it to my document. However, I don't have very good content for that se= ction. We had the ESCAPE workshop partly to try to find ways that Web Packa= ging might increase the risk of consolidation, and Martin is writing the re= port from there, but I didn't come away with any mechanisms that seem l= ikely to have a big effect.

Martin, do you have a = good list of ways folks are worried that Packaging will centralize service = providers?

Ben, do you have any examples of charte= rs that have incorporated this kind of discussion? I'd like to be able = to copy the structure if possible.

Thanks,
Jeffrey
--000000000000bdd02d058f8b00bf-- From nobody Wed Aug 7 11:39:55 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 26F2C1206D2 for ; Wed, 7 Aug 2019 11:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 30MjIKNoEbZl for ; Wed, 7 Aug 2019 11:39:44 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 7C44C1206C9 for ; Wed, 7 Aug 2019 11:39:36 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x77IW3Nk007153; Wed, 7 Aug 2019 19:39:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=2U1LKIh57uquvI63GUY1GEjuExljoASksAPy/J8oh54=; b=UfL0UOfawx+Nonoc22qmbwJ5M9jPmtoH/FjfcQSbe90D0lqcvZrb5n0D6kkN+ec5myv8 gYbFQTN+aNCJvqt+z1PNUP2ZsSRWMV6Dvu/CW9i8JUHvZ6PBpQecaq8HNv5qOIaWuN9y V0kR/ES6SFcZpCvchVsBzQHDcF0ENh9AbWB3jgyrT3kLiVQG+xDRUVSWjd0tVXv5E2ep 2awbi1CAbIJTE2xt14+A6B4nDKkydnnoF0svF+CDICoEp91bKFwDkTdIiovr3gWZ2SWX FVcutwuLZcnt1dUW9SxG8LTlkQ0vLKBS2xd8Iln9byFx+nezIT0BtVYtutBcdqjFMX9U nQ== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2u51wv24qn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Aug 2019 19:39:33 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x77IX0Y7021951; Wed, 7 Aug 2019 11:39:33 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint5.akamai.com with ESMTP id 2u5888fhcb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 07 Aug 2019 11:39:33 -0700 Received: from usma1ex-dag3mb1.msg.corp.akamai.com (172.27.123.60) by usma1ex-dag3mb5.msg.corp.akamai.com (172.27.123.55) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 14:39:32 -0400 Received: from usma1ex-dag3mb1.msg.corp.akamai.com ([172.27.123.60]) by usma1ex-dag3mb1.msg.corp.akamai.com ([172.27.123.60]) with mapi id 15.00.1473.005; Wed, 7 Aug 2019 14:39:32 -0400 From: "Kaduk, Ben" To: Jeffrey Yasskin , Martin Thomson CC: "wpack@ietf.org" Thread-Topic: [Wpack] Problem statement and scope for BoF Thread-Index: AQHVS7Y5P2Xfw7nBnUqi+Ma2G0oslqbtdmmAgAK5ggD//65tAIAAZvMA//+P5QA= Date: Wed, 7 Aug 2019 18:39:32 +0000 Message-ID: <36092786-D5D9-4BC6-BEC0-7E6E7A7181E4@akamai.com> References: <20190807171218.GB19909@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.230] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-07_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=866 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908070170 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-07_05:2019-08-07,2019-08-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 bulkscore=0 mlxlogscore=835 priorityscore=1501 adultscore=0 lowpriorityscore=0 mlxscore=0 spamscore=0 phishscore=0 clxscore=1011 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908070170 Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF 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, 07 Aug 2019 18:39:54 -0000 T24gOC83LzE5LCAxMToyMSwgIkplZmZyZXkgWWFzc2tpbiIgPGp5YXNza2luQGdvb2dsZS5jb20+ IHdyb3RlOg0KIA0KPiAgICBCZW4sIGRvIHlvdSBoYXZlIGFueSBleGFtcGxlcyBvZiBjaGFydGVy cyB0aGF0IGhhdmUgaW5jb3Jwb3JhdGVkIHRoaXMga2luZCBvZiBkaXNjdXNzaW9uPyBJJ2QgbGlr ZSB0byBiZSBhYmxlIHRvIGNvcHkgdGhlIHN0cnVjdHVyZSBpZiBwb3NzaWJsZS4NCg0KVW5mb3J0 dW5hdGVseSBub3Q7IG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBpdCdzIGJlZW4gYSBmYWlybHkg cmVjZW50IHJldmVsYXRpb24gdGhhdCB3ZSBzaG91bGQgZXhwbGljaXRseSBiZSB0aGlua2luZyBh Ym91dCBvdXIgd29yayBpbiB0aGlzIHdheS4NCg0KU29ycnksDQoNCkJlbg0KIA0KDQo= From nobody Wed Aug 7 11:46:14 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 2B58012028B for ; Wed, 7 Aug 2019 11:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, URIBL_BLOCKED=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 jEp5LtTPYrTR for ; Wed, 7 Aug 2019 11:46:11 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 39829120152 for ; Wed, 7 Aug 2019 11:46:11 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id m8so52851719lji.7 for ; Wed, 07 Aug 2019 11:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=idvjx9vnHMuQoiz1iCfVufsuGBP+opnWbgUnRyyGQM4=; b=BLDCcv/y+BASATt47yIq04MRwTauPmo08BC4o0KVULIi2ohIx1cw9JYgcMoEMxF96o lShIxsh7bdfArswUc4JQ9YetgcMIytk1dh8geBmMM73ITM15SdcKL/dC3iOTGQ9Yt3Ny OJJWoNjS8niGno2eJCG355k6Rd0WDXW0pGN+xdojCdg8VyuMTeakrcyqN7MMZbXs/Xgi 4PXiqzwjFd7wT6dNkiULzsbI7JZChHcSe14p8ER+Oor1xXKnnH/J7M1eJEkSWbVT3BUP 1nv7QGxIzeYGEQ6Xk/bQcrGyp8XYBbfy6uEdsmlF4c1MOlSxH8fpCNf0WQDpXdEiPY7N qGRA== 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=idvjx9vnHMuQoiz1iCfVufsuGBP+opnWbgUnRyyGQM4=; b=YzCPLKN5Exs5OLWIBh2Z9ZXKZrTKzy4KWj4GdCnIi4lkmVUDz+dN42we0lS/7vcrX3 /kzyb97Uv3xFVNJW2Veh5x6soWRi3ZS9ovYBy6oZZMe7vnjbc1Lh3wq7P6a/0+IJc4Sh b7dZtpLtwNCuAPKzmC0uT/SOpZrLuaKmPEXbLTa5ayqkjXEu6x52yqCct7WEdp1WKBe5 ou6AIox6hBYJXkkQ3zxFfIEt8DehlST+TXwrIozkOkQFKfGq282dPDDBZZ0ukS/wlcld OFBiHc184TtP4W5dAOD+eeW2XIw/WY1ackWlFP5OZoQRZHILQeW0ZBk3KOaAFJfzjBsj N83g== X-Gm-Message-State: APjAAAXH19/XKb2MMYwufMNNI/wjru2P0BxvDTng3HXZc29znHH7WAZS 9QocGDIyD1pipRdcJy+hjKBsqYPKCrj/BrwW9Kj2NQ== X-Google-Smtp-Source: APXvYqwPHERBpR9jXis/AC7/gxOyvzCwOMxudQKOE5MBpPl8BGvug52CMYXBpyLbV4PZNb3N32u86OgRFrQyGpM2t4E= X-Received: by 2002:a2e:86c3:: with SMTP id n3mr5856256ljj.129.1565203568878; Wed, 07 Aug 2019 11:46:08 -0700 (PDT) MIME-Version: 1.0 References: <20190807171218.GB19909@akamai.com> <36092786-D5D9-4BC6-BEC0-7E6E7A7181E4@akamai.com> In-Reply-To: <36092786-D5D9-4BC6-BEC0-7E6E7A7181E4@akamai.com> From: Jeffrey Yasskin Date: Wed, 7 Aug 2019 11:45:57 -0700 Message-ID: To: "Kaduk, Ben" Cc: Martin Thomson , "wpack@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b9d825058f8b5a33" Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF 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, 07 Aug 2019 18:46:13 -0000 --000000000000b9d825058f8b5a33 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 7, 2019 at 11:39 AM Kaduk, Ben wrote: > On 8/7/19, 11:21, "Jeffrey Yasskin" wrote: > > > Ben, do you have any examples of charters that have incorporated this > kind of discussion? I'd like to be able to copy the structure if possible. > > Unfortunately not; my understanding is that it's been a fairly recent > revelation that we should explicitly be thinking about our work in this way. > No worries. I mostly expected that but was hoping to be surprised. :) We'll make something up and iterate. Thanks, Jeffrey --000000000000b9d825058f8b5a33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 7, 2019 at 11:39 AM Kaduk, Be= n <bkaduk@akamai.com> wrote:=
On 8/7/19, 11:21, "Jeffrey Yasskin" <jyasskin@google.com> wro= te:

>=C2=A0 =C2=A0 Ben, do you have any examples of charters that have incor= porated this kind of discussion? I'd like to be able to copy the struct= ure if possible.

Unfortunately not; my understanding is that it's been a fairly recent r= evelation that we should explicitly be thinking about our work in this way.=
=C2=A0
No worries. I mostly expected that b= ut was hoping to be surprised. :) We'll make something up and iterate.<= /div>

Thanks,
Jeffrey
--000000000000b9d825058f8b5a33-- From nobody Wed Aug 7 11:46: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 2057C1202E1 for ; Wed, 7 Aug 2019 11:46:54 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 Qjw2kU146oQH for ; Wed, 7 Aug 2019 11:46:52 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 8BEEF120152 for ; Wed, 7 Aug 2019 11:46:50 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x77IW1OL014582; Wed, 7 Aug 2019 19:46:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=pL55HUBUfTHqt/IrBPTwqDhuxWxLmbRbZgX7Y1JMMHQ=; b=EV2u2yXQQcA5sA4li5pZGrcoJ3eiEgpNTo2lnW38Dx+9WkrWqPcPlzCfhPYP+HcIC+de yIxYTDCimTMsBGnFQRqBbkyt3kSQi1FmCVD5HxukiF2yt3kvuTcco/qbhGuM7tN/n3Jy IDJ9IZZtfU+64bsGN0f3tBUSQH0ay5oukh27iGSkvw1u9ZoB7kLt8mBeCuDfyryoH0y2 67xt+Nj/UEQCDAt53kfd/zOk5ZO4BXM8p2U8+IA5Ht51jO02v7s9VJm+AbD7EFADM/Wl dvmBjfcAYcNar7LfKyf5XtptlV/7wekOhKBqKR2NGGzcoMRvONvQCWOJgXezzaCLzLbE Ag== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2u51t4ms3s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Aug 2019 19:46:46 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x77IX6HM022042; Wed, 7 Aug 2019 11:46:45 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint5.akamai.com with ESMTP id 2u5888fhp2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 07 Aug 2019 11:46:45 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 14:46:44 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Wed, 7 Aug 2019 14:46:44 -0400 From: "Salz, Rich" To: Jeffrey Yasskin CC: "wpack@ietf.org" Thread-Topic: [Wpack] Problem statement and scope for BoF Thread-Index: AQHVS7Y5soTKl9Q6r0ibFluHsp3M6KbtM1uAgAL8kAD//9mTAA== Date: Wed, 7 Aug 2019 18:46:44 +0000 Message-ID: <245D3939-6FF6-47B4-A353-F394844BE0C5@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.97] Content-Type: multipart/alternative; boundary="_000_245D39396FF647B4A353F394844BE0C5akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-07_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=958 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908070170 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-07_05:2019-08-07,2019-08-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 priorityscore=1501 mlxscore=0 mlxlogscore=931 spamscore=0 clxscore=1015 adultscore=0 phishscore=0 malwarescore=0 bulkscore=0 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908070170 Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF 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, 07 Aug 2019 18:46:54 -0000 --_000_245D39396FF647B4A353F394844BE0C5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGUgdXNlIGNhc2UgaXMgYnJvYWRlciB0aGFuIGp1c3Qgb25lIGZyYW1ld29yayBvciBwaWVj ZSBvZiBzZWFyY2ggcmVzdWx0IFVJLCBzbyBpdCBzZWVtZWQgd3JvbmcgdG8gY2FsbCBvdXQgcGFy dGljdWxhciBicmFuZHMuDQoNCkkgZGlkIG5vdCBtZW50aW9uIGFueSBicmFuZHMgaW4gbXkgbm90 ZSwgSSBvbmx5IG1lbnRpb25lZCB0d28gdXNlIGNhc2VzLg0KDQo+VGhlIGluZmVyZW5jZSBJJ20g Z29pbmcgZm9yIGhlcmUgaXMgdGhhdCwgaWYgdXNlcnMgaGF2ZSB0dXJuZWQgb2ZmIG9yIHJ1biBv dXQgb2YgdGhlaXIgZGF0YSwgZXZlbiBiZWNhdXNlIG9mIG5hdGl2ZS1hcHAgbWlzYmVoYXZpb3Is IHRoZXkgY2FuJ3QgdGhlbiBicm93c2UgdG8gYW5kIGluc3RhbGwgYSB3ZWIgYXBwLiBJJ20gaGF2 aW5nIHRyb3VibGUgY29taW5nIHVwIHdpdGggd29yZGluZyB0aGF0IHdvdWxkIG1ha2UgdGhhdCBj bGVhcmVyIHdpdGhvdXQgYmVpbmcgdG9vIHdvcmR5LiBBbnkgaWRlYXM/DQoNCkkgdGhpbmsgeW91 IGp1c3Qgd3JvdGUgaXQgaW4gdGhlIHNlbnRlbmNlIGFib3ZlLiA6KQ0KDQo= --_000_245D39396FF647B4A353F394844BE0C5akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <6A73D43DA2B7A84FB5C14F10C227AE45@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7PC9zcGFuPjwv Yj4gVGhlIHVzZSBjYXNlIGlzIGJyb2FkZXIgdGhhbiBqdXN0IG9uZSBmcmFtZXdvcmsgb3IgcGll Y2Ugb2Ygc2VhcmNoIHJlc3VsdCBVSSwgc28gaXQgc2VlbWVkIHdyb25nIHRvIGNhbGwgb3V0IHBh cnRpY3VsYXIgYnJhbmRzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkaWQgbm90 IG1lbnRpb24gYW55IGJyYW5kcyBpbiBteSBub3RlLCBJIG9ubHkgbWVudGlvbmVkIHR3byB1c2Ug Y2FzZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtUaGUgaW5m ZXJlbmNlIEknbSBnb2luZyBmb3IgaGVyZSBpcyB0aGF0LCBpZiB1c2VycyBoYXZlIHR1cm5lZCBv ZmYgb3IgcnVuIG91dCBvZiB0aGVpciBkYXRhLCBldmVuIGJlY2F1c2Ugb2YgbmF0aXZlLWFwcCBt aXNiZWhhdmlvciwgdGhleSBjYW4ndCB0aGVuIGJyb3dzZSB0byBhbmQgaW5zdGFsbCBhIHdlYiBh cHAuIEknbSBoYXZpbmcgdHJvdWJsZSBjb21pbmcgdXAgd2l0aCB3b3JkaW5nIHRoYXQgd291bGQN CiBtYWtlIHRoYXQgY2xlYXJlciB3aXRob3V0IGJlaW5nIHRvbyB3b3JkeS4gQW55IGlkZWFzPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHlvdSBqdXN0IHdy b3RlIGl0IGluIHRoZSBzZW50ZW5jZSBhYm92ZS4gOik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_245D39396FF647B4A353F394844BE0C5akamaicom_-- From nobody Wed Aug 7 16:22:58 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 4F2E41200DF for ; Wed, 7 Aug 2019 16:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, URIBL_BLOCKED=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 AztgHVXAIIuK for ; Wed, 7 Aug 2019 16:22:53 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 1AC24120033 for ; Wed, 7 Aug 2019 16:22:53 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id m23so86974907lje.12 for ; Wed, 07 Aug 2019 16:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eEwOdYv37PPnzXj45riU4qpShET8CAMVSzDpJSNqyl4=; b=sq8uogyLGgjCAaJwLt4iuayesJOFL1MzPB1To7uA/RHm+TiBf1CQV0rkKGL+mT5ZHC Lev1XNlwzDGgVcydjDXhs9e4aS/ybTmY9cjzUlbATznpcO+41o3T6ntEsTKXmIFPZrUw 6Qs6y4n0ubhDpkNtjs/eLZ2GiOX7saanR3c9oNXoj3GXItgifQNL56lpoq6GIoBoi0gw gFflbNVnH94W5DoIEjOlswVd006axs1mmMmlAu7um6tiab/yiQoQafVC/920SsSyCtLK V5uLolCNGhz2cCS6i2ZUTsJHwzdAxvA+zhXj0ATVe3mmFzPAnqNsnfk6yz/xZq+/HARj 0OUQ== 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=eEwOdYv37PPnzXj45riU4qpShET8CAMVSzDpJSNqyl4=; b=cJTsep11FKRZAxBEKajSKX4iANcKjQ1r31LaXe8uiBlfmlCugns6vQp9oZzSubYCCm 3HmjDiJkaiACUmbnqXvJY1Mz/MV9NSBDKaoqF63VPSOPYgBs8orxUbiuHthZxBRTmfxG iFBDAOn9T8RRa7tE8F5qPqP7wuPlxqFEGTn2D2fmC7bTO1ojPgNJXzC4UUJRl84F9P4d tCD3RNgMC+lrCx0pplg6V+z1qnmaB++ztlnxq+pdqTLnTP390Vfri5fVr7RNaY1W30aF MWvYM46m2I+81ER69TkZtbvTN0j/1Ck/lsCAayxIPayPkzoxCZO1/EiTQvUoRcKCFZJ2 ku3w== X-Gm-Message-State: APjAAAWd9KXGOxVyayb1yR5hrIHWGfOj8OXmKs7Wq/WsWhxDa7tZX787 hJpa6VRM8kIs53kH9t6SAGAgZp2ZXm3eGc+iYzKxd8yNkWleqg== X-Google-Smtp-Source: APXvYqzTLXzbqnjN7qlpzpUlxADrqk4sW3bzMpf83MHZHRtwNLijqk/B0PSZ4keUZJPM9v4zohfEdKCIXgx0gGIVTxg= X-Received: by 2002:a2e:9643:: with SMTP id z3mr6318854ljh.43.1565220170495; Wed, 07 Aug 2019 16:22:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Wed, 7 Aug 2019 16:22:37 -0700 Message-ID: To: "Salz, Rich" Cc: "wpack@ietf.org" Content-Type: multipart/alternative; boundary="000000000000424db9058f8f38e5" Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF 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, 07 Aug 2019 23:22:56 -0000 --000000000000424db9058f8f38e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Inline: On Wed, Aug 7, 2019 at 10:14 AM Salz, Rich wrote: > > * Other users run out of paid-for data in their mobile plan part-way > through a month, or aggressively disable mobile data to make sure it'= s > not wasted. > > Strike this item; there is *zero* data to indicate that it is because of > users (inadvertently) loading web pages, as opposed to other reasons, suc= h > as push notifications, geo-tracking, and so on. > I think our messages crossed and you do think it's ok to mention that users without data can't load web pages even if they don't have data because of a native app's misbehavior? I've tried "Users can't fetch websites if they've run out of paid-for data in their mobile plan part-way through a month or if they've aggressively disabled mobile data to make sure other apps don't waste it in the background." > These users currently have to, at best, tell their browsers to > pre-fetch sites when they have a cheap real-time connection available > or wait until they find such a connection, and at worst, can't browse > the content at all. > > Yes, this characterizes the previous items. HOWEVER, I strongly suggest > that we need a new first item, and this paragraph then becomes diluted. > Some restructuring will be necessary. > > > Even users with highly-available internet connections want to be abl= e > to read and interact with web pages as quickly as possible after > clicking a link. Needing to make extra connections in the critical > path, and having multiple connections competing for bandwidth without > the ability to prioritize, interfere with that goal. > > I am not sure I agree with this. There is a large body of user experienc= e > studies that show how long a delay can be and zero isn't it. :) > > NEW FIRST ITEM. I believe the following captures the real driver behind > this work. So much so that this should be the first listed motivator of t= he > problem statement. While the other use-cases are important, I am less > sanguine -- or perhaps just more cynical -- that those things will ever b= e > addressed. The main driver has billions of dollars behind it after all. > > * Third-party aggregators, such as social media and search engines, want > to push external content to the user while the page is being loaded and/o= r > displayed. This enables previews, or thumbnails, etc., to be displayed > without the user committing to seeing the full content (and therefore > without the origin getting notification). All three parties -- the user, > the origin, and the aggregator -- want this content to be cryptographical= ly > secure and tamper-evident. > Thank you for the suggested wording. I think it's explained to me one place we're miscommunicating here and in your ESCAPE paper. While aggregators do want to push external content to the user while the referring page is being displayed, it's not to enable previews, since those could be done with a referring-origin image. The only (I think?) place cross-origin-signed content is actually required is in loading the next page quickly, at which point the origin gets notification, either via unsigned subresources, Javascript, or (not fleshed out yet) the Reporting API . I do still have the impression that the IETF values the "other use cases" over this one, and that if we want to maximize the chances of those other use cases actually being addressed, we should emphasize them in the charter= . I prefer to have discussions on the mailing list for greater visibility, > archiving, and because it's more IETF-like. > That works for me. Are you ok with maintaining the current state of the document in Google Docs, or would you rather it move to Github? My experience is that Docs is better for collaborative authoring, but if other folks prefer another storage location, I can deal. On Wed, Aug 7, 2019 at 10:19 AM Salz, Rich wrote: > >I'm happy to take changes here, but I need those changes to be designed > to maximize the chance of chartering a working group. The ideal change > comes with a statement along the lines of "I don't support chartering a W= G > with the current problem/scope/charter, but I would support it after this > change." Rich, judging from your ESCAPE submission, you don't want the IE= TF > to do this work at all, so I worry that if I take your suggestions, it'll > make the IETF less likely to create the WG. If I've misread your post, an= d > you actually think the IETF is enthusiastic to prioritize AMP first, let = me > know. > > > > So I only get one chance to make suggestions or comments? And if, after > that one change I=E2=80=99m not willing to commit to supporting your proj= ect you > will ignore me? > > > > Surely, you don=E2=80=99t mean that, and I am just mis-reading what you w= rote, and > I look forward to seeing your correction. > > Indeed: I don't expect all or even most the changes I take to be "ideal"; I just need to be confident that they're motivated by increasing the chance that a WG is created, and then increasing the quality of the work that WG winds up doing. Thanks, Jeffrey --000000000000424db9058f8f38e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inline:

On Wed, Aug 7, 2019 at 10:14 AM Salz, Rich <rsalz@akamai.com> wrote:
>=C2=A0 =C2=A0 * = Other users run out of paid-for data in their mobile plan part-way
=C2=A0 =C2=A0 through a month, or aggressively disable mobile data to make = sure it's
=C2=A0 =C2=A0 not wasted.

Strike this item; there is *zero* data to indicate that it is because of us= ers (inadvertently) loading web pages, as opposed to other reasons, such as= push notifications, geo-tracking, and so on.

I think our messages crossed and you do think it's ok to mention= that users without data can't load web pages even if they don't ha= ve data because of a native app's misbehavior? I've tried "Users can't fetch websi= tes if they've run out of paid-for data in their mobile plan part-way t= hrough a month or if they've aggressively disabled mobile data to make = sure other apps don't waste it in the background."

<= /div>
>=C2=A0 =C2=A0 These users currently have to, at best, tell their browse= rs to
=C2=A0 =C2=A0 pre-fetch sites when they have a cheap real-time connection a= vailable
=C2=A0 =C2=A0 or wait until they find such a connection, and at worst, can&= #39;t browse
=C2=A0 =C2=A0 the content at all.

Yes, this characterizes the previous items.=C2=A0 HOWEVER, I strongly sugge= st that we need a new first item, and this paragraph then becomes diluted.= =C2=A0 Some restructuring will be necessary.

>=C2=A0 =C2=A0 Even users with highly-available internet connections wan= t to be able
=C2=A0 =C2=A0 to read and interact with web pages as quickly as possible af= ter
=C2=A0 =C2=A0 clicking a link. Needing to make extra connections in the cri= tical
=C2=A0 =C2=A0 path, and having multiple connections competing for bandwidth= without
=C2=A0 =C2=A0 the ability to prioritize, interfere with that goal.

I am not sure I agree with this.=C2=A0 There is a large body of user experi= ence studies that show how long a delay can be and zero isn't it. :)
NEW FIRST ITEM.=C2=A0 I believe the following captures the real driver behi= nd this work. So much so that this should be the first listed motivator of = the problem statement. While the other use-cases are important, I am less s= anguine -- or perhaps just more cynical -- that those things will ever be a= ddressed.=C2=A0 The main driver has billions of dollars behind it after all= .

* Third-party aggregators, such as social media and search engines, want to= push external content to the user while the page is being loaded and/or di= splayed. This enables previews, or thumbnails, etc., to be displayed withou= t the user committing to seeing the full content (and therefore without the= origin getting notification). All three parties -- the user, the origin, a= nd the aggregator -- want this content to be cryptographically secure and t= amper-evident.

Thank you for the sugges= ted wording. I think it's explained to me one place we're miscommun= icating here and in your ESCAPE paper. While aggregators do want to push ex= ternal content to the user while the referring page is being displayed, it&= #39;s not to enable previews, since those could be done with a referring-or= igin image. The only (I think?) place cross-origin-signed content is actual= ly required is in loading the next page quickly, at which point the origin = gets notification, either via unsigned subresources, Javascript, or (not fl= eshed out yet) the Reporting A= PI.

I do still have the impression that the IE= TF values the "other use cases" over this one, and that if we wan= t to maximize the chances of those other use cases actually being addressed= , we should emphasize them in the charter.

I prefer to have discussions on the mailing list for greater visibility, ar= chiving, and because it's more IETF-like.

That works for me. Are you ok with maintaining the current state of = the document in Google Docs, or would you rather it move to Github? My expe= rience is that Docs is better for collaborative authoring, but if other fol= ks prefer another storage location, I can deal.

On Wed, Aug 7, 2019 at 10:19 AM Salz, R= ich <rsalz@akamai.com> wrote:=

>I'm happy to take changes here, but I need t= hose changes to be designed to maximize the chance of chartering a working = group. The ideal change comes with a statement along the lines of "I d= on't support chartering a WG with the current problem/scope/charter, but I would support it after this change." Ric= h, judging from your ESCAPE submission, you don't want the IETF to do t= his work at all, so I worry that if I take your suggestions, it'll make= the IETF less likely to create the WG. If I've misread your post, and you actually think the IETF is enthusiastic to prio= ritize AMP first, let me know.

=C2=A0

So I only get one chance to make suggestions or comm= ents? And if, after that one change I=E2=80=99m not willing to commit to su= pporting your project you will ignore me?

=C2=A0

Surely, you don=E2=80=99t mean that, and I am just m= is-reading what you wrote, and I look forward to seeing your correction.=


Indeed: I don't expect all or even most the changes I take to be &qu= ot;ideal"; I just need to be confident that they're motivated by i= ncreasing the chance that a WG is created, and then increasing the quality = of the work that WG winds up doing.

Thanks,<= /div>
Jeffrey
--000000000000424db9058f8f38e5-- From nobody Wed Aug 7 16:52:51 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 DF98212008A for ; Wed, 7 Aug 2019 16:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=IwSlJ68r; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Dd1TKDFw 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 66nEbWN5f5Mo for ; Wed, 7 Aug 2019 16:52:48 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D12120033 for ; Wed, 7 Aug 2019 16:52:48 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 484E5360 for ; Wed, 7 Aug 2019 19:52:47 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 07 Aug 2019 19:52:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=6M5B2lns8KR784YYJlIoyMDe1yE6/Ta 2FlvdhpN8Ep4=; b=IwSlJ68rXlcNjsDdaWiVj+nTFNVtFITl/yWMUhVh2O5C+Vt eP3cB9TaIarQh6Sa03Hma+fUv6kaYckHAtKINCvfM4Cw8h3ASBev4PSvKcLPNwC+ 32/VHinNoBZWSl837Mup1e63sKNlP1XOymxQoJ9wmtUD87zlcsKqT11Es39BC5CX sl2+KNrITkcLx/2jPnsiBS5BSbJ3Z/jRpgfptmU3ESQTxTfigcZ5TnBOsu67wx+Z yJZhgD7mCZRFoSOiwAZnnYJeaJODNooTsX+53zDDeMfWHLEUMWWpuKZyZYMcMH8Z DhNnU73Kj9DpHrS2bii5KuPOF982LFoZemwGRWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=6M5B2l ns8KR784YYJlIoyMDe1yE6/Ta2FlvdhpN8Ep4=; b=Dd1TKDFw7Jj1GnXbYXEoRU CELxntd8AEfaNUGUbr+Av6t/qhcTCHjQ8tp8Mltt4phKDp1kgczaCjZ7r9Ym/iYj KmgdEn/fcmPXB2rPCzC9M4ficwSfmmufP7xEWdoMljmB7QuVcR0lVIcwOOjlZQmT ZUcb5I8lR+FPYmKgs02EfGtsjvPnOxqEtqJvAvR8SsuixDot4PD6fvMYwBjI/als 9iqfMCtoMsHl+DSr/fjJtowarZok80ZuU99vJVrjYyT23s7a+T9hTjIbsvhRflUL w5hnfjcMO1AVlMMAP+SUykfFKxOA+xooLwkyESVzXD8hdbHbiOtq5hRBlGKouu9A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddugecutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtredtre ertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnh htrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 855D9E00A2; Wed, 7 Aug 2019 19:52:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-808-g930a1a1-fmstable-20190805v2 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20190807171218.GB19909@akamai.com> Date: Thu, 08 Aug 2019 09:52:38 +1000 From: "Martin Thomson" To: wpack@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF 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, 07 Aug 2019 23:52:50 -0000 On Thu, Aug 8, 2019, at 04:21, Jeffrey Yasskin wrote: > That's a great point, and I'm adding a section > [...] for it to my document. However, I don't have very good content for that section. We had the ESCAPE workshop partly to try to find ways that Web Packaging might increase the risk of consolidation, and Martin is writing the report from there, but I didn't come away with any mechanisms that seem likely to have a big effect. I agree that there wasn't much at the workshop that suggested how this could avoid some of the consolidation effects. > > Martin, do you have a good list of ways folks are worried that > Packaging will centralize service providers? Mozilla's position paper has my best thinking on that subject, but a few points for the purposes of summary... The consolidation effects might be felt in several ways: in terms of driving traffic to sites that have the resources to preload links, in terms of inventivizing provision of content for majority clients, and as a secondary effect of raising the cost of business for publishers. The latter point is not one standards organizations are well-equipped to handle. It's a natural byproduct of having more standards. There are two ways of dealing with that: 1. Stop adding to the pile. I know it's hard to tell engineers not to engineer, so I don't expect this to happen. New stuff is just too appealing. 2. Having more and more accessible software for handling any complexity. For instance, HTTPS didn't really take off until we had really good support infrastructure. Jeffrey has done some of that with the tools around building packages, but that's a very small part of the picture. We need more and better tools, including cognitive tools for understanding the effect of this sort of change. The availability of those tools will always lag standardization. I might speculate and say that the extent to which consolidation is driven by this sort of effort will depend on how big that lag is. From nobody Thu Aug 8 04:47:07 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 2C7591202DE for ; Thu, 8 Aug 2019 04:46:54 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 OZ7Bv4XqUZk4 for ; Thu, 8 Aug 2019 04:46:52 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 7FC83120158 for ; Thu, 8 Aug 2019 04:46:52 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x78BgDdR022481; Thu, 8 Aug 2019 12:46:50 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=uNADOrUgaj578DJQ2iqcZ4z6vppszk9xInNxaA7hNBo=; b=PJ8RqWAxiQ+rE604PEbxw7aaT6teDHYdTIfdVfy3XevIQ+oHWDGgMo7rcUQFn+xogAMb E3mAuOMKaDVcSgJi9eRooHZgJqF7KxNo5bkPCI9McZ2tNFPjbSU+MFUfF1ha/VxNsSC1 PdhAG/2d9ARwI88dnWDol2LxwtzqRUjBCYTogqVWGFhhAQ6QZxkv+laiHtDkeqW/n9om 3D7Kre/FyVky/ZVZjUXwkOno7DRVhftEklpT9WZ261+3lC+gb1/xsrsMZjeN9zSHdCq/ q43Q97uOd15nd8IRo9ECX7oOYp2f/UC4jW9WoqjtokCXzAkM1TUJkf+t83+W/nTPtbF6 MA== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2u51wv53u1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Aug 2019 12:46:50 +0100 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x78BWr4w006418; Thu, 8 Aug 2019 07:46:49 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint8.akamai.com with ESMTP id 2u55kvj4fw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 08 Aug 2019 07:46:49 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 8 Aug 2019 07:46:48 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 8 Aug 2019 07:46:47 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Thu, 8 Aug 2019 07:46:47 -0400 From: "Salz, Rich" To: Jeffrey Yasskin CC: "wpack@ietf.org" Thread-Topic: [Wpack] Problem statement and scope for BoF Thread-Index: AQHVS7Y5soTKl9Q6r0ibFluHsp3M6Kbv76eAgACp+oCAAIzbAA== Date: Thu, 8 Aug 2019 11:46:46 +0000 Message-ID: <9115ACAF-9F61-4D8F-B842-C1262DAC8E86@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.124] Content-Type: multipart/alternative; boundary="_000_9115ACAF9F614D8FB842C1262DAC8E86akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-08_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=725 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908080123 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-08_06:2019-08-07,2019-08-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 bulkscore=0 mlxlogscore=719 priorityscore=1501 adultscore=0 lowpriorityscore=0 mlxscore=0 spamscore=0 phishscore=0 clxscore=1015 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908080125 Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF 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, 08 Aug 2019 11:47:05 -0000 --_000_9115ACAF9F614D8FB842C1262DAC8E86akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJIGp1c3QgbmVlZCB0byBiZSBjb25maWRlbnQgdGhhdCB0aGV5J3JlIG1vdGl2YXRlZCBieSBp bmNyZWFzaW5nIHRoZSBjaGFuY2UgdGhhdCBhIFdHIGlzIGNyZWF0ZWQsIGFuZCB0aGVuIGluY3Jl YXNpbmcgdGhlIHF1YWxpdHkgb2YgdGhlIHdvcmsgdGhhdCBXRyB3aW5kcyB1cCBkb2luZy4NCg0K TXkgbW90aXZhdGlvbiBpcyB0byBpbmNyZWFzZSB3aGF0IEkgc2VlIGFzIHRoZSBhY2N1cmFjeSBv ZiB0aGUgc3RhdGVtZW50LiAgV2XigJlyZSBhbGwgbGlrZSB0aGUgYmxpbmQgcGVvcGxlIGFuZCB0 aGUgZWxlcGhhbnQgSSBndWVzcy4NCg0KVGhhbmtzLg0K --_000_9115ACAF9F614D8FB842C1262DAC8E86akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <597036FD54DBC14C898395E9CD2E57D2@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7PC9zcGFuPjwv Yj4gSSBqdXN0IG5lZWQgdG8gYmUgY29uZmlkZW50IHRoYXQgdGhleSdyZSBtb3RpdmF0ZWQgYnkg aW5jcmVhc2luZyB0aGUgY2hhbmNlIHRoYXQgYSBXRyBpcyBjcmVhdGVkLCBhbmQgdGhlbiBpbmNy ZWFzaW5nIHRoZSBxdWFsaXR5IG9mIHRoZSB3b3JrIHRoYXQgV0cgd2luZHMgdXAgZG9pbmcuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBtb3RpdmF0aW9uIGlzIHRvIGluY3JlYXNl IHdoYXQgSSBzZWUgYXMgdGhlIGFjY3VyYWN5IG9mIHRoZSBzdGF0ZW1lbnQuJm5ic3A7IFdl4oCZ cmUgYWxsIGxpa2UgdGhlIGJsaW5kIHBlb3BsZSBhbmQgdGhlIGVsZXBoYW50IEkgZ3Vlc3MuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9115ACAF9F614D8FB842C1262DAC8E86akamaicom_-- From nobody Thu Aug 8 14:35: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 31CCA120098 for ; Thu, 8 Aug 2019 14:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 cwfvCbHcf1bu for ; Thu, 8 Aug 2019 14:35:52 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700100.outbound.protection.outlook.com [40.107.70.100]) (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 6EAEE120073 for ; Thu, 8 Aug 2019 14:35:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dL38vRjbWB379wQVtlQ1V69NvajBwYeFSSXc39/1tXe2SyKzVM5ei77sAgLwslWhqSl3zy+KsTNKQ6iMLUV0Zs19Rnuz57SccoX3mb8/X6qNtJbyccmAvNuK5+brqulklC5Lh91ZmJu/uBaKOf3xkZhoRPxVx7wDWbhCjV0MOCpqQ1RQJz1iiMJq6laQsleaoxbUEHyuXH8BGJa21wPNmcsFdWh5qq+lF1gi+RbIfvX86WfElEnLU+wAfaNjFCf8mDBVR0IDkqYZurzYoOcLbA/4ykrHPmitnZtVzzhulj6lLxq3mS9MefT0fsj7qjKEs6NgPW9CGKUyaULcZUhqgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=awsNFAlRa/Qci7TQMJ2LTtg97ObiY2+5sL4BUCccGEk=; b=Vtg0OX0CEBQp9SKfxCU1dUL6KukLLUH2zLfXxt1m6K10em23LRVKIqYdVdFU8obZiRlEenyA1OrFgrm+21wXlPHc3BqDtf/IwOcZu1RsnsMn17KlMX+1LTmtMzJRln8JwT6TuRLSzdVlIqvkbnwErLz2iS3LVqqde7CMUL8gKeXKigDi4na4uaH2TaHezbseVyJI8PI+Io5Fr7lT/qKdr6yZUBhJHhFN4ML/HHluZBZCNSGPmRjxTxwXXebVjl6DoXMRD8M7dIxRHKM/hml+Y7OHQJ+p2bbm6mufMTR4seg2b6M1UoKCbiOF8U+/7C1InwPzGtE0CIdH5YsrV7VE2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=evequefou.be;dmarc=pass action=none header.from=evequefou.be;dkim=pass header.d=evequefou.be;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=awsNFAlRa/Qci7TQMJ2LTtg97ObiY2+5sL4BUCccGEk=; b=VMn5aXKDi/RVK43xPhA8uRhBbijbPPK3h3ZHK7XE1INzQ7JV2sLSnhjq591FgsfS29GoLxWN12KLcKE2PkO+c8eo8mAbOPMlLc68vuUfdMXdOFPPFmGyu1Dl3BWEsw9WUXhUxwugpUxs4LG61Fh3EsJq9lWYy0JcjMZCLC9NBh4= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0871.namprd22.prod.outlook.com (10.171.165.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Thu, 8 Aug 2019 21:35:49 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::4190:c9d6:bf3f:2432]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::4190:c9d6:bf3f:2432%4]) with mapi id 15.20.2157.015; Thu, 8 Aug 2019 21:35:49 +0000 From: Mike Bishop To: Jeffrey Yasskin , "Salz, Rich" CC: "wpack@ietf.org" Thread-Topic: [Wpack] Problem statement and scope for BoF Thread-Index: AQHVS7Y4inxvGJSy80uVPHEDViFcVabtM1uAgAK5ggCAAdsyEA== Date: Thu, 8 Aug 2019 21:35:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2600:2b00:9323:fe01:b9d1:269e:154e:50a9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fb0158be-32fb-488b-5f1e-08d71c486181 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR22MB0871; x-ms-traffictypediagnostic: CY4PR22MB0871: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(346002)(39830400003)(376002)(199004)(189003)(55016002)(110136005)(5660300002)(86362001)(508600001)(8936002)(76116006)(81166006)(14454004)(81156014)(476003)(7736002)(8676002)(52536014)(7696005)(316002)(486006)(2906002)(66556008)(229853002)(4326008)(71190400001)(71200400001)(6506007)(10126004)(64756008)(6246003)(11346002)(53546011)(14444005)(256004)(66476007)(74316002)(66446008)(66946007)(25786009)(46003)(54896002)(99286004)(6116002)(790700001)(76176011)(102836004)(33656002)(186003)(446003)(6436002)(66574012)(53936002)(6306002)(236005)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0871; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: xkij54Nvv7RTDyufpRRhEOMmRtCquIbsPpo+fRQY5YP4lN2rtiSODPI7HnxY58jIirE+3Msewzz4nItKINrQZdaJqI6PiRspfAiJHL4Xz44wCxIqhgtk070N2b6sulHnK4Q4jf0yBzLVGl1U8A7Sf4Uip+NrK+TXVJ6Se2A5tESDTRHFuJ3NbgKM1ps3wuuoD2v1BnXqHSRvwD8fpMkuRzOc/tOtI55OSFaTx6Y0HbhQYjFC9KnhCyPehJOYfDAvE3T5nZ/TpARYBcMPKTcs1wIPWb4ZD5FqScoSKa3QX+dsJkVhJKDLlnljHjwRxYNdvYsBj0cTl17NJzlIqoJl0l6OAMXesAHWOkqtnGEIa5DEK7CAxh1As0MpKCvOy/Xf9SH3HQv+vunxi3XuTsGhswka/S92Gj2oKZNW4S8rU9E= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983B89C296B97844C2E33A3DAD70CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: fb0158be-32fb-488b-5f1e-08d71c486181 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 21:35:49.3756 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Fy+MRhDKz0NlFBzG15M5iurfXkbpDIqu23Pv0hAIVeh4m3YeEWrg/DcAyPBNU8+x3qydR721Rt6xx84giPGt2w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0871 Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF 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, 08 Aug 2019 21:35:56 -0000 --_000_CY4PR22MB0983B89C296B97844C2E33A3DAD70CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWxsIHJldmlldyBhbmQgY29tbWVudCBvbiB0aGUgYWN0dWFsIHByb2JsZW0gc3RhdGVtZW50 IGxhdGVyOyByaWdodCBub3csIEnigJltIHJlcGx5aW5nIHNvbGVseSB0byB0aGlzIGUtbWFpbC4N Cg0KVGhhbmsgeW91IGZvciBjbGVhcmx5IHN0YXRpbmcgeW91ciBzdGFuZGFyZCBmb3IgdGFraW5n IGNoYW5nZXM7IEkgd291bGQgc3VibWl0IHRoYXQgaXTigJlzIHRoZSB3cm9uZyBzdGFuZGFyZC4g IFRoZSBwb2ludCBvZiBhIEJvRiBpcyBub3QgdGhlIGZvcm1hdGlvbiBvZiBhIHdvcmtpbmcgZ3Jv dXAuICBJdOKAmXMgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIElFVEYgYXMgYSB3aG9sZSBkZXNp cmVzIHRvIHRha2UgdXAgYSBjZXJ0YWluIHByb2plY3Qg4oCTIHdoZXRoZXIgdGhlIHByb2plY3Qg aXMgY2xlYXJseSBkZWZpbmVkIGFuZCB0aGVyZSBhcmUgZW5vdWdoIHBlb3BsZSBpbnRlcmVzdGVk IGluIGRvaW5nIHRoZSB3b3JrLiAgSWYgYSBjaGFuZ2UgdG8gdGhlIHByb2JsZW0gc3RhdGVtZW50 IGFuZCBzY29wZSBtYWtlcyBpdCBlYXNpZXIgZm9yIHRoZSBJRVRGIHRvIG1ha2UgdGhhdCBhc3Nl c3NtZW50LCBpdOKAmXMgYmVuZWZpY2lhbCwgZXZlbiBpZiB0aGUgZXZlbnR1YWwgYXNzZXNzbWVu dCBpcyB0aGF0IHRoZSBJRVRGIGRvZXNu4oCZdCB3YW50IHRvIGRvIGl0Lg0KDQpOb3QgdG8gc2F5 IHRoYXQgd2UgZG8gb3IgZG9u4oCZdCDigJMgYnV0IEkgYmVsaWV2ZSB5b3VyIHJvbGUgaXMgdG8g aGVscCB0aGUgSUVTRyBtYWtlIGFuIGluZm9ybWVkIGRlY2lzaW9uLCBub3QgbWVyZWx5IHRvIHNo ZXBoZXJkIHRoZW0gdG8gYSBwYXJ0aWN1bGFyIHByZWRldGVybWluZWQgZGVjaXNpb24uDQoNCkZy b206IFdwYWNrIDx3cGFjay1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSmVmZnJleSBZ YXNza2luDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCA3LCAyMDE5IDE6MDQgUE0NClRvOiBTYWx6 LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPg0KQ2M6IHdwYWNrQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW1dwYWNrXSBQcm9ibGVtIHN0YXRlbWVudCBhbmQgc2NvcGUgZm9yIEJvRg0KDQpPbiBNb24s IEF1ZyA1LCAyMDE5IGF0IDQ6MjggUE0gU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbTxtYWls dG86cnNhbHpAYWthbWFpLmNvbT4+IHdyb3RlOg0KQ29tbWVudGluZyBvbmx5IG9uIHRoZSAicHJv YmxlbSIgcGFydCBvZiB5b3VyIHBvc3Q7IEkgcmVzZXJ2ZSB0aGUgcmlnaHQgdG8gY29tbWVudCBv biBvdGhlciBwYXJ0cyBsYXRlciA6KQ0KDQpJIGFtIHN1cnByaXNlZCB0aGF0IHNlYXJjaCBjYXJv dXNlbCBhbmQgQU1QIGlzbid0IG1lbnRpb25lZCwgYXMgZnJhbmtseSBpdCBpcyB0aGUgdXNlLWNh c2Ugd2l0aCB0aGUgbW9zdCBlY29ub21pYyBpbmNlbnRpdmUvaW1wYWN0LiBIb25lc3R5IGNvbXBl bHMgdXMgdG8gZXhwbGljaXRseSBtZW50aW9uIGl0LCBwbGFpbmx5LCBhbmQgZmlyc3QuDQoNClRo ZSBBTVAgYW5kIFNlYXJjaCBDYXJvdXNlbCB1c2UgY2FzZSBpcyBtZW50aW9uZWQgYXMgIkV2ZW4g dXNlcnMgd2l0aCBoaWdobHktYXZhaWxhYmxlIGludGVybmV0IGNvbm5lY3Rpb25zIHdhbnQgdG8g YmUgYWJsZSB0byByZWFkIGFuZCBpbnRlcmFjdCB3aXRoIHdlYiBwYWdlcyBhcyBxdWlja2x5IGFz IHBvc3NpYmxlIGFmdGVyIGNsaWNraW5nIGEgbGluay4iIFRoZSB1c2UgY2FzZSBpcyBicm9hZGVy IHRoYW4ganVzdCBvbmUgZnJhbWV3b3JrIG9yIHBpZWNlIG9mIHNlYXJjaCByZXN1bHQgVUksIHNv IGl0IHNlZW1lZCB3cm9uZyB0byBjYWxsIG91dCBwYXJ0aWN1bGFyIGJyYW5kcy4NCg0KRnVydGhl ciwgbXkgaW1wcmVzc2lvbiBvZiBJRVRGIGNoYXJ0ZXJzIGlzIHRoYXQgdGhleSBkaXNjdXNzIGFu ZCBwcmlvcml0aXplIHRoZSBnb2FscyBvZiB0aGUgSUVURiB3b3JraW5nIGdyb3VwLCBub3QganVz dCB0aGUgZ29hbHMgb2YgdGhlIGNvbXBhbnkgZW1wbG95aW5nIHRoZSBpbmRpdmlkdWFscyB3aG8g YXJlIHByb3Bvc2luZyB0aGUgV0cuIE15IGltcHJlc3Npb24gaXMgdGhhdCB0aGUgSUVURiBzZXRz IGEgbG93ZXIgcHJpb3JpdHkgb24gZml4aW5nIHRoZSBBTVAgVVJMIHByb2JsZW0gdGhhbiBpbXBy b3ZpbmcgYWNjZXNzIHRvIHRoZSBnbG9iYWwgaW50ZXJuZXQsIHNvIEkgd3JvdGUgdGhlIGhpZ2hl ciBwcmlvcml0eSB1c2UgY2FzZSBmaXJzdC4NCg0KSXQncyB0cnVlIHRoYXQgYSBsb3Qgb2YgR29v Z2xlJ3MgaW52ZXN0bWVudCBpbiB0aGUgcHJvYmxlbSBpcyBkcml2ZW4gYnkgdHJ5aW5nIHRvIGZp eCB0aGluZ3MgYXJvdW5kIEFNUCwgYnV0IEkgdGhpbmsgaXQncyBmYWlyIHRvIHNvbHZlIGEgcHJv YmxlbSBmb3IgbGVzcy13ZWFsdGh5IHVzZXJzIGJ5IHVzaW5nIGZ1bmRpbmcgZnJvbSBhIHdlYWx0 aGllciBjbGllbnQgd2hvIGNhbiBhbHNvIGJlbmVmaXQgZnJvbSB0aGUgc2FtZSBzb2x1dGlvbi4N Cg0KSSdtIGhhcHB5IHRvIHRha2UgY2hhbmdlcyBoZXJlLCBidXQgSSBuZWVkIHRob3NlIGNoYW5n ZXMgdG8gYmUgZGVzaWduZWQgdG8gbWF4aW1pemUgdGhlIGNoYW5jZSBvZiBjaGFydGVyaW5nIGEg d29ya2luZyBncm91cC4gVGhlIGlkZWFsIGNoYW5nZSBjb21lcyB3aXRoIGEgc3RhdGVtZW50IGFs b25nIHRoZSBsaW5lcyBvZiAiSSBkb24ndCBzdXBwb3J0IGNoYXJ0ZXJpbmcgYSBXRyB3aXRoIHRo ZSBjdXJyZW50IHByb2JsZW0vc2NvcGUvY2hhcnRlciwgYnV0IEkgd291bGQgc3VwcG9ydCBpdCBh ZnRlciB0aGlzIGNoYW5nZS4iIFJpY2gsIGp1ZGdpbmcgZnJvbSB5b3VyIEVTQ0FQRSBzdWJtaXNz aW9uLCB5b3UgZG9uJ3Qgd2FudCB0aGUgSUVURiB0byBkbyB0aGlzIHdvcmsgYXQgYWxsLCBzbyBJ IHdvcnJ5IHRoYXQgaWYgSSB0YWtlIHlvdXIgc3VnZ2VzdGlvbnMsIGl0J2xsIG1ha2UgdGhlIElF VEYgbGVzcyBsaWtlbHkgdG8gY3JlYXRlIHRoZSBXRy4gSWYgSSd2ZSBtaXNyZWFkIHlvdXIgcG9z dCwgYW5kIHlvdSBhY3R1YWxseSB0aGluayB0aGUgSUVURiBpcyBlbnRodXNpYXN0aWMgdG8gcHJp b3JpdGl6ZSBBTVAgZmlyc3QsIGxldCBtZSBrbm93Lg0KDQo+ICAgICogT3RoZXIgdXNlcnMgcnVu IG91dCBvZiBwYWlkLWZvciBkYXRhIGluIHRoZWlyIG1vYmlsZSBwbGFuIHBhcnQtd2F5DQogICAg dGhyb3VnaCBhIG1vbnRoLCBvciBhZ2dyZXNzaXZlbHkgZGlzYWJsZSBtb2JpbGUgZGF0YSB0byBt YWtlIHN1cmUgaXQncw0KICAgIG5vdCB3YXN0ZWQuDQoNCldlIGhhdmUgc2VlbiBubyBldmlkZW5j ZSB0aGF0IHRoaXMgaXMgZG9uZSBiZWNhdXNlIG9mIHN1cmZpbmcsIGFzIG9wcG9zZWQgdG8gdHJh Y2tpbmcgb3Igb3RoZXIgYXBwIGFjdGl2aXR5Lg0KDQpJIGFncmVlLiBUaGUgaW5mZXJlbmNlIEkn bSBnb2luZyBmb3IgaGVyZSBpcyB0aGF0LCBpZiB1c2VycyBoYXZlIHR1cm5lZCBvZmYgb3IgcnVu IG91dCBvZiB0aGVpciBkYXRhLCBldmVuIGJlY2F1c2Ugb2YgbmF0aXZlLWFwcCBtaXNiZWhhdmlv ciwgdGhleSBjYW4ndCB0aGVuIGJyb3dzZSB0byBhbmQgaW5zdGFsbCBhIHdlYiBhcHAuIEknbSBo YXZpbmcgdHJvdWJsZSBjb21pbmcgdXAgd2l0aCB3b3JkaW5nIHRoYXQgd291bGQgbWFrZSB0aGF0 IGNsZWFyZXIgd2l0aG91dCBiZWluZyB0b28gd29yZHkuIEFueSBpZGVhcz8NCg0KSmVmZnJleQ0K --_000_CY4PR22MB0983B89C296B97844C2E33A3DAD70CY4PR22MB0983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmWxsIHJl dmlldyBhbmQgY29tbWVudCBvbiB0aGUgYWN0dWFsIHByb2JsZW0gc3RhdGVtZW50IGxhdGVyOyBy aWdodCBub3csIEnigJltIHJlcGx5aW5nIHNvbGVseSB0byB0aGlzIGUtbWFpbC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IGZvciBjbGVhcmx5IHN0YXRpbmcgeW91ciBzdGFuZGFy ZCBmb3IgdGFraW5nIGNoYW5nZXM7IEkgd291bGQgc3VibWl0IHRoYXQgaXTigJlzIHRoZSB3cm9u ZyBzdGFuZGFyZC4gJm5ic3A7VGhlIHBvaW50IG9mIGEgQm9GIGlzIG5vdCB0aGUgZm9ybWF0aW9u IG9mIGEgd29ya2luZyBncm91cC4mbmJzcDsgSXTigJlzIHRvIGRldGVybWluZSB3aGV0aGVyIHRo ZSBJRVRGIGFzIGEgd2hvbGUgZGVzaXJlcyB0byB0YWtlIHVwDQogYSBjZXJ0YWluIHByb2plY3Qg 4oCTIHdoZXRoZXIgdGhlIHByb2plY3QgaXMgY2xlYXJseSBkZWZpbmVkIGFuZCB0aGVyZSBhcmUg ZW5vdWdoIHBlb3BsZSBpbnRlcmVzdGVkIGluIGRvaW5nIHRoZSB3b3JrLiZuYnNwOyBJZiBhIGNo YW5nZSB0byB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHNjb3BlIG1ha2VzIGl0IGVhc2llciBm b3IgdGhlIElFVEYgdG8gbWFrZSB0aGF0IGFzc2Vzc21lbnQsIGl04oCZcyBiZW5lZmljaWFsLCBl dmVuIGlmIHRoZSBldmVudHVhbA0KIGFzc2Vzc21lbnQgaXMgdGhhdCB0aGUgSUVURiBkb2VzbuKA mXQgd2FudCB0byBkbyBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IHRvIHNheSB0aGF0 IHdlIGRvIG9yIGRvbuKAmXQg4oCTIGJ1dCBJIGJlbGlldmUgeW91ciByb2xlIGlzIHRvIGhlbHAg dGhlIElFU0cgbWFrZSBhbiBpbmZvcm1lZCBkZWNpc2lvbiwgbm90IG1lcmVseSB0byBzaGVwaGVy ZCB0aGVtIHRvIGEgcGFydGljdWxhciBwcmVkZXRlcm1pbmVkIGRlY2lzaW9uLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gV3BhY2sgJmx0O3dwYWNrLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpKZWZmcmV5IFlhc3NraW48YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgNywgMjAxOSAxOjA0IFBNPGJyPg0KPGI+VG86PC9iPiBT YWx6LCBSaWNoICZsdDtyc2FsekBha2FtYWkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gd3BhY2tA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtXcGFja10gUHJvYmxlbSBzdGF0ZW1l bnQgYW5kIHNjb3BlIGZvciBCb0Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBNb24sIEF1ZyA1LCAyMDE5IGF0IDQ6MjggUE0gU2FseiwgUmljaCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJzYWx6QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj5yc2FsekBha2FtYWkuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29tbWVudGluZyBvbmx5IG9uIHRoZSAmcXVvdDtwcm9i bGVtJnF1b3Q7IHBhcnQgb2YgeW91ciBwb3N0OyBJIHJlc2VydmUgdGhlIHJpZ2h0IHRvIGNvbW1l bnQgb24gb3RoZXIgcGFydHMgbGF0ZXIgOik8YnI+DQo8YnI+DQpJIGFtIHN1cnByaXNlZCB0aGF0 IHNlYXJjaCBjYXJvdXNlbCBhbmQgQU1QIGlzbid0IG1lbnRpb25lZCwgYXMgZnJhbmtseSBpdCBp cyB0aGUgdXNlLWNhc2Ugd2l0aCB0aGUgbW9zdCBlY29ub21pYyBpbmNlbnRpdmUvaW1wYWN0LiBI b25lc3R5IGNvbXBlbHMgdXMgdG8gZXhwbGljaXRseSBtZW50aW9uIGl0LCBwbGFpbmx5LCBhbmQg Zmlyc3QuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgQU1QIGFuZCBTZWFyY2ggQ2Fyb3VzZWwgdXNlIGNhc2UgaXMgbWVudGlv bmVkIGFzICZxdW90O0V2ZW4gdXNlcnMgd2l0aCBoaWdobHktYXZhaWxhYmxlIGludGVybmV0IGNv bm5lY3Rpb25zIHdhbnQgdG8gYmUgYWJsZSB0byByZWFkIGFuZCBpbnRlcmFjdCB3aXRoIHdlYiBw YWdlcyBhcyBxdWlja2x5IGFzIHBvc3NpYmxlIGFmdGVyIGNsaWNraW5nIGEgbGluay4mcXVvdDsg VGhlIHVzZSBjYXNlIGlzIGJyb2FkZXIgdGhhbg0KIGp1c3Qgb25lIGZyYW1ld29yayBvciBwaWVj ZSBvZiBzZWFyY2ggcmVzdWx0IFVJLCBzbyBpdCBzZWVtZWQgd3JvbmcgdG8gY2FsbCBvdXQgcGFy dGljdWxhciBicmFuZHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkZ1cnRoZXIsIG15IGltcHJlc3Npb24gb2YgSUVURiBjaGFydGVycyBpcyB0 aGF0IHRoZXkgZGlzY3VzcyBhbmQgcHJpb3JpdGl6ZSB0aGUgZ29hbHMgb2YgdGhlIElFVEYgd29y a2luZyBncm91cCwgbm90IGp1c3QgdGhlIGdvYWxzIG9mIHRoZSBjb21wYW55IGVtcGxveWluZyB0 aGUgaW5kaXZpZHVhbHMgd2hvIGFyZSBwcm9wb3NpbmcgdGhlIFdHLiBNeSBpbXByZXNzaW9uIGlz IHRoYXQgdGhlIElFVEYgc2V0cyBhDQogbG93ZXIgcHJpb3JpdHkgb24gZml4aW5nIHRoZSBBTVAg VVJMIHByb2JsZW0gdGhhbiBpbXByb3ZpbmcgYWNjZXNzIHRvIHRoZSBnbG9iYWwgaW50ZXJuZXQs IHNvIEkgd3JvdGUgdGhlIGhpZ2hlciBwcmlvcml0eSB1c2UgY2FzZSBmaXJzdC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQncyB0cnVlIHRo YXQgYSBsb3Qgb2YgR29vZ2xlJ3MgaW52ZXN0bWVudCBpbiB0aGUgcHJvYmxlbSBpcyBkcml2ZW4g YnkgdHJ5aW5nIHRvIGZpeCB0aGluZ3MgYXJvdW5kIEFNUCwgYnV0IEkgdGhpbmsgaXQncyBmYWly IHRvIHNvbHZlIGEgcHJvYmxlbSBmb3IgbGVzcy13ZWFsdGh5IHVzZXJzIGJ5IHVzaW5nIGZ1bmRp bmcgZnJvbSBhIHdlYWx0aGllciBjbGllbnQgd2hvIGNhbiBhbHNvIGJlbmVmaXQgZnJvbQ0KIHRo ZSBzYW1lIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JJ20gaGFwcHkgdG8gdGFrZSBjaGFuZ2VzIGhlcmUsIGJ1dCBJIG5lZWQg dGhvc2UgY2hhbmdlcyB0byBiZSBkZXNpZ25lZCB0byBtYXhpbWl6ZSB0aGUgY2hhbmNlIG9mIGNo YXJ0ZXJpbmcgYSB3b3JraW5nIGdyb3VwLiBUaGUgaWRlYWwgY2hhbmdlIGNvbWVzIHdpdGggYSBz dGF0ZW1lbnQgYWxvbmcgdGhlIGxpbmVzIG9mICZxdW90O0kgZG9uJ3Qgc3VwcG9ydCBjaGFydGVy aW5nIGEgV0cgd2l0aCB0aGUgY3VycmVudCBwcm9ibGVtL3Njb3BlL2NoYXJ0ZXIsDQogYnV0IEkg d291bGQgc3VwcG9ydCBpdCBhZnRlciB0aGlzIGNoYW5nZS4mcXVvdDsgUmljaCwganVkZ2luZyBm cm9tIHlvdXIgRVNDQVBFIHN1Ym1pc3Npb24sIHlvdSBkb24ndCB3YW50IHRoZSBJRVRGIHRvIGRv IHRoaXMgd29yayBhdCBhbGwsIHNvIEkgd29ycnkgdGhhdCBpZiBJIHRha2UgeW91ciBzdWdnZXN0 aW9ucywgaXQnbGwgbWFrZSB0aGUgSUVURiBsZXNzIGxpa2VseSB0byBjcmVhdGUgdGhlIFdHLiBJ ZiBJJ3ZlIG1pc3JlYWQgeW91ciBwb3N0LCBhbmQNCiB5b3UgYWN0dWFsbHkgdGhpbmsgdGhlIElF VEYgaXMgZW50aHVzaWFzdGljIHRvIHByaW9yaXRpemUgQU1QIGZpcnN0LCBsZXQgbWUga25vdy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OyZuYnNwOyAmbmJzcDsgKiBPdGhlciB1c2VycyBydW4gb3V0IG9mIHBhaWQtZm9yIGRh dGEgaW4gdGhlaXIgbW9iaWxlIHBsYW4gcGFydC13YXk8YnI+DQombmJzcDsgJm5ic3A7IHRocm91 Z2ggYSBtb250aCwgb3IgYWdncmVzc2l2ZWx5IGRpc2FibGUgbW9iaWxlIGRhdGEgdG8gbWFrZSBz dXJlIGl0J3M8YnI+DQombmJzcDsgJm5ic3A7IG5vdCB3YXN0ZWQuPGJyPg0KPGJyPg0KV2UgaGF2 ZSBzZWVuIG5vIGV2aWRlbmNlIHRoYXQgdGhpcyBpcyBkb25lIGJlY2F1c2Ugb2Ygc3VyZmluZywg YXMgb3Bwb3NlZCB0byB0cmFja2luZyBvciBvdGhlciBhcHAgYWN0aXZpdHkuPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVl LiBUaGUgaW5mZXJlbmNlIEknbSBnb2luZyBmb3IgaGVyZSBpcyB0aGF0LCBpZiB1c2VycyBoYXZl IHR1cm5lZCBvZmYgb3IgcnVuIG91dCBvZiB0aGVpciBkYXRhLCBldmVuIGJlY2F1c2Ugb2YgbmF0 aXZlLWFwcCBtaXNiZWhhdmlvciwgdGhleSBjYW4ndCB0aGVuIGJyb3dzZSB0byBhbmQgaW5zdGFs bCBhIHdlYiBhcHAuIEknbSBoYXZpbmcgdHJvdWJsZSBjb21pbmcgdXAgd2l0aCB3b3JkaW5nIHRo YXQNCiB3b3VsZCBtYWtlIHRoYXQgY2xlYXJlciB3aXRob3V0IGJlaW5nIHRvbyB3b3JkeS4gQW55 IGlkZWFzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5KZWZmcmV5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR22MB0983B89C296B97844C2E33A3DAD70CY4PR22MB0983namp_-- From nobody Thu Aug 8 17:02:39 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 CF5FE120047 for ; Thu, 8 Aug 2019 17:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, URIBL_BLOCKED=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 o1SjhfEmGCu4 for ; Thu, 8 Aug 2019 17:02:34 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 21033120025 for ; Thu, 8 Aug 2019 17:02:34 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id z17so2048522ljz.0 for ; Thu, 08 Aug 2019 17:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k3iOS6uhUofYleLZLtDQBPIoA2N4c2WKS81YVESGsVo=; b=T90zC1OATe5OheR1TkEFOc6HVTuHmqSbsWFuojTpQCA9Xl8KzMVZgow2JKRBEqSm8K y1xLFRDMXnyC/qBZwT5a6BeEnHy1yRa/26QoGeHhAnrbAJU4nS6cT5SUKa9uqSu1qP0d Qin3WApXQlGOwnKnffFdKcFMgycFn8aH2xfN9oTMlmHSZSj987AkX4voNXr2GgpqE26Y V1sl/cthLtA4BDNI4gzuhrfxApvFCoS6/ugSNVFZ4Ff8H3wP/Pq1ehrVce87cooq4PB7 5TD3UbofqLI0fWn4XCo21c+AqiNBeQI6Q0P1PzFUbFYoTJ/3KDdvcBtXAreFIgGU4eOR LLlg== 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=k3iOS6uhUofYleLZLtDQBPIoA2N4c2WKS81YVESGsVo=; b=kfPVNQAa3h0NoQL6rv7EdlPD/LkRC0+ym7CeMAWQ1r9aZcURlmMIm1uhZaOYmvwFty TzjDUxqs4eHrURva7draDFGyNYcp/dXaH7CfxYtfKZP0AQcsdcgwVrEou0AnFUx2VW+h Cnh16U3RlDf2hqIXCfm6+MnjbTsrVJw3F8vApFiNzMBFQfbYpMcFflEyJNC64nOKnaEG WSxz01iVYigZ97zDT2B7Zs14b2B/gLXFNqvZ2LXDx8sds2ILy+iQ2tic+uh1iqE4jyKQ 6gd7bOAjK1rdr3MHqzyIf/KDdM39JDZnsDrwHs7PnInMxfGK2/KRFbnL+XL3X50Cjr5T yYFw== X-Gm-Message-State: APjAAAV3SvF34l5DwkR8gGHeU9uUaJoCdkVHd1HXWNvC3gSvXwUgQ/Yt o5VcxLN72s/2Kupi2Kl6A9jA0Jkj9T9Lq/lB0J4RqwbF7eb4sg== X-Google-Smtp-Source: APXvYqxF0Rqz3KcaOd70h+zQBUOoG8iRR8eZq1W4fcb7SKEcgdv1mW7DNYKWEXw3uWCEbQWKqRL5xYl9D/JynehuY/Q= X-Received: by 2002:a2e:86c3:: with SMTP id n3mr10046249ljj.129.1565308951503; Thu, 08 Aug 2019 17:02:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Thu, 8 Aug 2019 17:02:17 -0700 Message-ID: To: Mike Bishop Cc: "Salz, Rich" , "wpack@ietf.org" Content-Type: multipart/alternative; boundary="000000000000050ca1058fa3e4db" Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF 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, 09 Aug 2019 00:02:37 -0000 --000000000000050ca1058fa3e4db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Mike. I agree that a clear statement after the BoF that ~"the IETF does not want to take up this project" would be one of the two useful outcomes, even though it's not the outcome I prefer. If the problem statement, scope, and charter do not "maximize the chance of chartering a working group", there's no way to get that clear statement, since one could tweak them to call the decision into question. I don't have a lot of experience with BoFs at the IETF, but it seems like the right place to add information that will help inform the IETF would be in parallel I-Ds and during the presentations at the BoF. Would it make sense to invite Rich or another skeptic to give one of those presentations? I'd be happy to review it for factual accuracy like I did with Mozilla's position paper. You can talk to MT about how that went. This does contradict the advice in https://tools.ietf.org/html/rfc5434#section-4, which recommends avoiding "presentations that do not directly support the goal" where "the goal is to form a WG". But think I'd rather have the room evaluate an organized presentation about why the IETF shouldn't do this than disorganized questions at the microphone. Am I still missing the point? Thanks, Jeffrey On Thu, Aug 8, 2019 at 2:35 PM Mike Bishop wrote: > I=E2=80=99ll review and comment on the actual problem statement later; ri= ght now, > I=E2=80=99m replying solely to this e-mail. > > > > Thank you for clearly stating your standard for taking changes; I would > submit that it=E2=80=99s the wrong standard. The point of a BoF is not t= he > formation of a working group. It=E2=80=99s to determine whether the IETF= as a > whole desires to take up a certain project =E2=80=93 whether the project = is clearly > defined and there are enough people interested in doing the work. If a > change to the problem statement and scope makes it easier for the IETF to > make that assessment, it=E2=80=99s beneficial, even if the eventual asses= sment is > that the IETF doesn=E2=80=99t want to do it. > > > > Not to say that we do or don=E2=80=99t =E2=80=93 but I believe your role = is to help the > IESG make an informed decision, not merely to shepherd them to a particul= ar > predetermined decision. > > > > *From:* Wpack *On Behalf Of * Jeffrey Yasskin > *Sent:* Wednesday, August 7, 2019 1:04 PM > *To:* Salz, Rich > *Cc:* wpack@ietf.org > *Subject:* Re: [Wpack] Problem statement and scope for BoF > > > > On Mon, Aug 5, 2019 at 4:28 PM Salz, Rich wrote: > > Commenting only on the "problem" part of your post; I reserve the right t= o > comment on other parts later :) > > I am surprised that search carousel and AMP isn't mentioned, as frankly i= t > is the use-case with the most economic incentive/impact. Honesty compels = us > to explicitly mention it, plainly, and first. > > > > The AMP and Search Carousel use case is mentioned as "Even users with > highly-available internet connections want to be able to read and interac= t > with web pages as quickly as possible after clicking a link." The use cas= e > is broader than just one framework or piece of search result UI, so it > seemed wrong to call out particular brands. > > > > Further, my impression of IETF charters is that they discuss and > prioritize the goals of the IETF working group, not just the goals of the > company employing the individuals who are proposing the WG. My impression > is that the IETF sets a lower priority on fixing the AMP URL problem than > improving access to the global internet, so I wrote the higher priority u= se > case first. > > > > It's true that a lot of Google's investment in the problem is driven by > trying to fix things around AMP, but I think it's fair to solve a problem > for less-wealthy users by using funding from a wealthier client who can > also benefit from the same solution. > > > > I'm happy to take changes here, but I need those changes to be designed t= o > maximize the chance of chartering a working group. The ideal change comes > with a statement along the lines of "I don't support chartering a WG with > the current problem/scope/charter, but I would support it after this > change." Rich, judging from your ESCAPE submission, you don't want the IE= TF > to do this work at all, so I worry that if I take your suggestions, it'll > make the IETF less likely to create the WG. If I've misread your post, an= d > you actually think the IETF is enthusiastic to prioritize AMP first, let = me > know. > > > > > * Other users run out of paid-for data in their mobile plan part-way > through a month, or aggressively disable mobile data to make sure it'= s > not wasted. > > We have seen no evidence that this is done because of surfing, as opposed > to tracking or other app activity. > > > > I agree. The inference I'm going for here is that, if users have turned > off or run out of their data, even because of native-app misbehavior, the= y > can't then browse to and install a web app. I'm having trouble coming up > with wording that would make that clearer without being too wordy. Any > ideas? > > > > Jeffrey > --000000000000050ca1058fa3e4db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Mike. I agree that a clear statement after the= BoF that ~"the IETF does not want to take up this project" would= be one of the two useful outcomes, even though it's not the outcome I = prefer.

If the problem statement, scope, and chart= er do not "maximize the chance of chartering a working group", th= ere's no way to get that clear statement, since one could tweak them to= call the decision into question.

I don't have= a lot of experience with BoFs at the IETF, but it seems like the right pla= ce to add information that will help inform the IETF would be in parallel I= -Ds and during the presentations at the BoF. Would it make sense to invite = Rich or another skeptic to give one of those presentations? I'd be happ= y to review it for factual accuracy like I did with Mozilla's position = paper. You can talk to MT about how that went. This does contradict the adv= ice in=C2=A0https= ://tools.ietf.org/html/rfc5434#section-4, which recommends avoiding &qu= ot;presentations that do not directly support the goal" where "th= e goal is to form a WG". But think I'd rather have the room evalua= te an organized presentation about why the IETF shouldn't do this than = disorganized questions at the microphone.

Am I sti= ll missing the point?

Thanks,
Jeffrey
On = Thu, Aug 8, 2019 at 2:35 PM Mike Bishop <mbishop@evequefou.be> wrote:

I=E2=80=99ll review and comment on the actual proble= m statement later; right now, I=E2=80=99m replying solely to this e-mail.

=C2=A0

Thank you for clearly stating your standard for taki= ng changes; I would submit that it=E2=80=99s the wrong standard.=C2=A0 The = point of a BoF is not the formation of a working group.=C2=A0 It=E2=80=99s = to determine whether the IETF as a whole desires to take up a certain project =E2=80=93 whether the project is clearly defined and the= re are enough people interested in doing the work.=C2=A0 If a change to the= problem statement and scope makes it easier for the IETF to make that asse= ssment, it=E2=80=99s beneficial, even if the eventual assessment is that the IETF doesn=E2=80=99t want to do it.

=C2=A0

Not to say that we do or don=E2=80=99t =E2=80=93 but= I believe your role is to help the IESG make an informed decision, not mer= ely to shepherd them to a particular predetermined decision.<= /p>

=C2=A0

From: Wpack <wpack-bounces@ietf.org> On Behalf = Of Jeffrey Yasskin
Sent: Wednesday, August 7, 2019 1:04 PM
To: Salz, Rich <rsalz@akamai.com>
Cc: wpack@ietf.o= rg
Subject: Re: [Wpack] Problem statement and scope for BoF

=C2=A0

On Mon, Aug 5, 2019 at 4:28 PM Salz, Rich <rsalz@akamai.com> wr= ote:

Commenting only on the "problem" part of y= our post; I reserve the right to comment on other parts later :)

I am surprised that search carousel and AMP isn't mentioned, as frankly= it is the use-case with the most economic incentive/impact. Honesty compel= s us to explicitly mention it, plainly, and first.

=C2=A0

The AMP and Search Carousel use case is mentioned as= "Even users with highly-available internet connections want to be abl= e to read and interact with web pages as quickly as possible after clicking= a link." The use case is broader than just one framework or piece of search result UI, so it seemed wrong to cal= l out particular brands.

=C2=A0

Further, my impression of IETF charters is that they= discuss and prioritize the goals of the IETF working group, not just the g= oals of the company employing the individuals who are proposing the WG. My = impression is that the IETF sets a lower priority on fixing the AMP URL problem than improving access to the = global internet, so I wrote the higher priority use case first.

=C2=A0

It's true that a lot of Google's investment = in the problem is driven by trying to fix things around AMP, but I think it= 's fair to solve a problem for less-wealthy users by using funding from= a wealthier client who can also benefit from the same solution.

=C2=A0

I'm happy to take changes here, but I need those= changes to be designed to maximize the chance of chartering a working grou= p. The ideal change comes with a statement along the lines of "I don&#= 39;t support chartering a WG with the current problem/scope/charter, but I would support it after this change." Rich, judging from your ES= CAPE submission, you don't want the IETF to do this work at all, so I w= orry that if I take your suggestions, it'll make the IETF less likely t= o create the WG. If I've misread your post, and you actually think the IETF is enthusiastic to prioritize AMP first, let m= e know.

=C2=A0

>=C2=A0 =C2=A0 * Other users run out of paid-for = data in their mobile plan part-way
=C2=A0 =C2=A0 through a month, or aggressively disable mobile data to make = sure it's
=C2=A0 =C2=A0 not wasted.

We have seen no evidence that this is done because of surfing, as opposed t= o tracking or other app activity.

=C2=A0

I agree. The inference I'm going for here is tha= t, if users have turned off or run out of their data, even because of nativ= e-app misbehavior, they can't then browse to and install a web app. I&#= 39;m having trouble coming up with wording that would make that clearer without being too wordy. Any ideas?<= /p>

=C2=A0

Jeffrey

--000000000000050ca1058fa3e4db-- From nobody Mon Aug 12 16:00:18 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 7A0F9120C06 for ; Mon, 12 Aug 2019 16:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zu_QC1Eep_VG for ; Mon, 12 Aug 2019 16:00:14 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 4F534120F2F for ; Mon, 12 Aug 2019 15:48:48 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id 62so70500926lfa.8 for ; Mon, 12 Aug 2019 15:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8G8POiudD8S9xviwMcvgKTx1GtFZXNQKnzB5uTeshLg=; b=m/1yaVUcO1zJ6BOMlgsPAbQXHgn7c6Tqiimr9Q+XdS0sVbuXb4Bg1JjyA7n625Lami 4rsJpH5vCCQXvXOpEkvasDH9oj5OXPa0HqVey2UXh7+G1i9b7UZ39Ru4qgIzOx3V3/0Q j2iT1d3tjKLFXaE7TXCjtC8mP+VqvrHj9nuhg= 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=8G8POiudD8S9xviwMcvgKTx1GtFZXNQKnzB5uTeshLg=; b=sKYGNdRaoi1tU7YfTq4WMjp5woK9AMKs44coftyg+VN6JO0rdQkNnircO9ENekHbt2 jsHoKLqmLVf4UbQAz58R0WuBc+6M07mxsvtGHEXBcm30GKhpysG30Uk1U4v+FKaP9+f6 qcXGeNJ45RjPMQsRRz7gxTJIaHwdI5kR8U/7i0VH0dQmV2V2n3aMXfnqSgciQc9+ao4R umEC8XO3wF0bJZvhoVrLdrXv0s1ucHOsnDbexI3F1TPe3zVw6zTolicOb5voh3t9zNpT D5RGM1aJw9BEc4QkKRmVmnM6viTe8l4+RXbgGeZlpzegwxyw6U0TOeTMjL8wqbKL1J1L s9KA== X-Gm-Message-State: APjAAAUjrz6Her3sYaUDg1FNpxWjbndnpl+KPwyyDZ3RdV/yUnlx3/1/ w5QATi8FoJJY5UupB6FK156ZgBfolhsVANlyundssPZiTs+7vA== X-Google-Smtp-Source: APXvYqweNwua0Son2op0pgDSVVIr+NWtDfpiY1/g1RZMBN/ijCgO2PoHdHhTqpkHis9pC4sIrsypk6O2Z6LoWtiwm6I= X-Received: by 2002:a19:6707:: with SMTP id b7mr21040615lfc.16.1565650125740; Mon, 12 Aug 2019 15:48:45 -0700 (PDT) MIME-Version: 1.0 References: <20190807171218.GB19909@akamai.com> In-Reply-To: From: Jeffrey Yasskin Date: Mon, 12 Aug 2019 15:48:32 -0700 Message-ID: To: Martin Thomson Cc: wpack@ietf.org Content-Type: multipart/alternative; boundary="00000000000096a3f7058ff3538c" Archived-At: Subject: Re: [Wpack] Problem statement and scope for BoF X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 23:00:17 -0000 --00000000000096a3f7058ff3538c Content-Type: text/plain; charset="UTF-8" Thanks for the summary. I've made sure everything here is mentioned in the draft charter document: > The consolidation effects might be felt in several ways: in terms of driving traffic to sites that have the resources to preload links https://docs.google.com/document/d/1OUZcl6yQSJ5eZxMrbo6O2tVRW_U_bv0PZUxAVtR1GYA/edit#bookmark=kix.f8rqaam5jvj3 > in terms of inventivizing provision of content for majority clients, https://docs.google.com/document/d/1OUZcl6yQSJ5eZxMrbo6O2tVRW_U_bv0PZUxAVtR1GYA/edit#bookmark=id.ehwkcplglqgw > as a secondary effect of raising the cost of business for publishers. https://docs.google.com/document/d/1OUZcl6yQSJ5eZxMrbo6O2tVRW_U_bv0PZUxAVtR1GYA/edit#bookmark=id.ewnchx4da6jc and https://docs.google.com/document/d/1OUZcl6yQSJ5eZxMrbo6O2tVRW_U_bv0PZUxAVtR1GYA/edit#bookmark=id.knz0ld5p7r8f I think I've also included all the concrete mechanisms you pointed out in https://www.iab.org/wp-content/IAB-uploads/2019/06/mozilla.pdf. Specifically: The "Centralization and control" section is covered by https://docs.google.com/document/d/1OUZcl6yQSJ5eZxMrbo6O2tVRW_U_bv0PZUxAVtR1GYA/edit#bookmark=kix.acmvx6oznsq, I think. There is additional discussion about the aggregator ranking power in that section, but no further statements about web packaging that I could find. The "certainly has the effect of applying pressure toward consolidation of market share in a few worrying ways" paragraph lists only 2 ways, which you've helpfully repeated in your email. I think that's it? Thanks, Jeffrey On Wed, Aug 7, 2019 at 4:52 PM Martin Thomson wrote: > On Thu, Aug 8, 2019, at 04:21, Jeffrey Yasskin wrote: > > That's a great point, and I'm adding a section > > [...] for it to my document. However, I don't have very good content for > that section. We had the ESCAPE workshop partly to try to find ways that > Web Packaging might increase the risk of consolidation, and Martin is > writing the report from there, but I didn't come away with any mechanisms > that seem likely to have a big effect. > > I agree that there wasn't much at the workshop that suggested how this > could avoid some of the consolidation effects. > > > > Martin, do you have a good list of ways folks are worried that > > Packaging will centralize service providers? > > Mozilla's position paper has my best thinking on that subject, but a few > points for the purposes of summary... > > The consolidation effects might be felt in several ways: in terms of > driving traffic to sites that have the resources to preload links, in terms > of inventivizing provision of content for majority clients, and as a > secondary effect of raising the cost of business for publishers. > > The latter point is not one standards organizations are well-equipped to > handle. It's a natural byproduct of having more standards. There are two > ways of dealing with that: > > 1. Stop adding to the pile. I know it's hard to tell engineers not to > engineer, so I don't expect this to happen. New stuff is just too > appealing. > > 2. Having more and more accessible software for handling any complexity. > For instance, HTTPS didn't really take off until we had really good support > infrastructure. Jeffrey has done some of that with the tools around > building packages, but that's a very small part of the picture. We need > more and better tools, including cognitive tools for understanding the > effect of this sort of change. The availability of those tools will always > lag standardization. I might speculate and say that the extent to which > consolidation is driven by this sort of effort will depend on how big that > lag is. > > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack > --00000000000096a3f7058ff3538c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the summary. I've made sure everything= here is mentioned in the draft charter document:

= >=C2=A0The consolidation effects might be felt in several ways: in terms= of driving traffic to sites that have the resources to preload links
=


> in t= erms of inventivizing provision of content for majority clients,
=

> as a second= ary effect of raising the cost of business for publishers.

The "Centralization and cont= rol" section is covered by=C2=A0https://docs.google.com/document/d/1OUZcl6yQSJ5eZxMrbo6O2tVRW_U_= bv0PZUxAVtR1GYA/edit#bookmark=3Dkix.acmvx6oznsq, I think. There is addi= tional discussion about the aggregator ranking power in that section, but n= o further statements about web packaging that I could find.
<= br>
The "certainly has the effect of applying pressure towar= d consolidation of market share in a few worrying ways" paragraph list= s only 2 ways, which you've helpfully repeated in your email.

I think that's it?

Thanks,
Jeffrey

On Wed, Aug 7, 2019 at 4:52 PM Martin Thomson= <mt@lowentropy.net> wrote:<= br>
On Thu, Aug 8, 2= 019, at 04:21, Jeffrey Yasskin wrote:
> That's a great point, and I'm adding a section
> [...] for it to my document. However, I don't have very good conte= nt for that section. We had the ESCAPE workshop partly to try to find ways = that Web Packaging might increase the risk of consolidation, and Martin is = writing the report from there, but I didn't come away with any mechanis= ms that seem likely to have a big effect.

I agree that there wasn't much at the workshop that suggested how this = could avoid some of the consolidation effects.
>
> Martin, do you have a good list of ways folks are worried that
> Packaging will centralize service providers?

Mozilla's position paper has my best thinking on that subject, but a fe= w points for the purposes of summary...

The consolidation effects might be felt in several ways: in terms of drivin= g traffic to sites that have the resources to preload links, in terms of in= ventivizing provision of content for majority clients, and as a secondary e= ffect of raising the cost of business for publishers.

The latter point is not one standards organizations are well-equipped to ha= ndle.=C2=A0 It's a natural byproduct of having more standards.=C2=A0 Th= ere are two ways of dealing with that:

1. Stop adding to the pile.=C2=A0 I know it's hard to tell engineers no= t to engineer, so I don't expect this to happen.=C2=A0 New stuff is jus= t too appealing.

2. Having more and more accessible software for handling any complexity.=C2= =A0 For instance, HTTPS didn't really take off until we had really good= support infrastructure.=C2=A0 Jeffrey has done some of that with the tools= around building packages, but that's a very small part of the picture.= =C2=A0 We need more and better tools, including cognitive tools for underst= anding the effect of this sort of change.=C2=A0 The availability of those t= ools will always lag standardization.=C2=A0 I might speculate and say that = the extent to which consolidation is driven by this sort of effort will dep= end on how big that lag is.

_______________________________________________
Wpack mailing list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo/wpack
--00000000000096a3f7058ff3538c-- From nobody Fri Aug 16 15:17:58 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 25D29120104 for ; Fri, 16 Aug 2019 15:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, URIBL_BLOCKED=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 qHFwh4v_1xyx for ; Fri, 16 Aug 2019 15:17:53 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 8FC05120018 for ; Fri, 16 Aug 2019 15:17:53 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id l1so617786lji.12 for ; Fri, 16 Aug 2019 15:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=DfVBDnKtWBqQIq0xGtEKVXlQVaTFCcbHfKzWrjtXYik=; b=mvWKTC/fhrBV82ALKHCNzupcIrvxb2SDGAYnzKOeZk9loLkPu4Eo88xa6HG6fB78Xr n43t2u/40RyTPSkiBLOdF6eVOsul6RKCfMHSKFM/pl2xS+0LPPfUArSytDtAy/ecHdH+ 3vtFvG0pvZPiUvEvrmq5StTUFpytvobrMvGIpao+DD0bcTjw5BX9J6bGl/92SY6EXrIl oNaG6Opci7F3lhAKf59MwAvB7cc/mr9pf3P7Gk9TcrWryxY9BPhx1Dj26pzjqXWnwY7O 9dzi60O8AGIm6XV6nbP6uoRlStLJvj2ViDaVqgbI45fllvtQd4wop+dgPfIhR7bCCyC1 79Hw== 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:cc; bh=DfVBDnKtWBqQIq0xGtEKVXlQVaTFCcbHfKzWrjtXYik=; b=k9d9P5dJhkb9SCY6yaGigvJV3PEkD7MtQbUpv9pUCutC/PUujvqiEe5UVSdWrDMQ8l +SNgX9ixx8B3mR8MB5ZkHXuObcFeBxRYaJkLMTyKVMSOOCv54g9BnpgaaaOpWfXkKcTZ rWj4MDgaIbfrT04/z+JAoC7x43eU/eGJaUjAbOTzcKA+Y6gO2C1vddGnjIgN4ahCpZjb NZxtkMOQ/KcEHserc6r9WzWv83F2lRKQgO7nAbKRj/PeMpSC8BBOAUkdqkXGCaDT7ZLS QlpqwZ68I5xdlODzn0vqiimskp5594RUsa0dRVCFQ3TBwbkaSnV1MikR9zDq8DCy5V/V 8pjg== X-Gm-Message-State: APjAAAVg5Iw1y6AC/YyRlMo+w6YSS54HMnkPIjr3NX9t/R2Lx+RNrYkz 6aYSNzgBisiSRVAPWzn6iME+p9OFaSLpVw8dTmzu4A== X-Google-Smtp-Source: APXvYqwrQzTl2oof+xkjk139Y/6P+a9+BdFqnxpvTjBS3McOFN5GJbCfYP8TKmwIkpdMNksVh1he2ToQhijCt5GahaA= X-Received: by 2002:a2e:9d9a:: with SMTP id c26mr6908720ljj.56.1565993871417; Fri, 16 Aug 2019 15:17:51 -0700 (PDT) MIME-Version: 1.0 From: Jeffrey Yasskin Date: Fri, 16 Aug 2019 15:17:40 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Ted Hardie , wpack@ietf.org Content-Type: multipart/alternative; boundary="0000000000006d8fbb0590435c94" Archived-At: Subject: [Wpack] Approach to use for web packaging media types 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, 16 Aug 2019 22:17:56 -0000 --0000000000006d8fbb0590435c94 Content-Type: text/plain; charset="UTF-8" Hi Murray (and wpack@ietf to keep folks in the loop), The web packaging draft specifications propose a couple media types, which we're experimenting with in Chromium. Specifically: https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#iana-considerations * application/signed-exchange * application/cert-chain+cbor https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html#internet-media-type-registration * application/webbundle These specifications haven't been accepted into an IETF WG yet, so I hadn't asked for provisional registration, but since we've already deployed some code using application/signed-exchange and are implementing support for application/webbundle, Ted Hardie suggested we get your advice on how to handle the media types. Do you expect to want us to change anything about how those media types are spelled? Since we're already writing the drafts under the WICG W3C Community Group, should I request provisional registrations now? Should we instead use the vnd. tree until an IETF WG adopts the drafts? Thanks, Jeffrey --0000000000006d8fbb0590435c94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Murray (and wpack@ietf to keep folks in the loop),
=
The web packaging draft specifications propose a couple medi= a types, which we're experimenting with in Chromium. Specifically:

*=C2=A0application/signed-exchange
= *=C2=A0application/cert-chain+cbor

https://wicg.github.io/webpackage/draft-yas= skin-wpack-bundled-exchanges.html#internet-media-type-registration
<= /div>
* application/webbundle

These specificat= ions haven't been accepted into an IETF WG yet, so I hadn't asked f= or provisional registration, but since we've already deployed some code= using application/signed-exchange and are implementing support for applica= tion/webbundle, Ted Hardie suggested we get your advice on how to handle th= e media types.

Do you expect to want us to change = anything about how those media types are spelled? Since we're already w= riting the drafts under the WICG W3C Community Group, should I request prov= isional registrations now? Should we instead use the vnd. tree until an IET= F WG adopts the drafts?

Thanks,
Jeffrey<= /div>
--0000000000006d8fbb0590435c94-- From nobody Mon Aug 19 10:22:47 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 20C2A120866 for ; Mon, 19 Aug 2019 10:22:44 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F6y6vKmWFon for ; Mon, 19 Aug 2019 10:22:42 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 07B66120859 for ; Mon, 19 Aug 2019 10:22:42 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id r10so933977uam.1 for ; Mon, 19 Aug 2019 10:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FUNBU7kw7u4/270uoC50G2VLxbYf9B5lkkkni8ASFoQ=; b=aeRujuaw6jUQHq6BbQEhEFIHpgfRGhujKQEpiuiybfeDRg+E3gFuzO+15CV9nxRUCQ 3Q3wAxEvmJ149b965OewXrlt+eprG6nlOfTFNezYdnRBJPl1oDSqa1AOFMztgEUEHOMA M33USPOyi1z/Ql9DZ1/m/ZGOg696Vw2QhzjI5gLDqW6NlOwBlgOzqtEUB90vmyBurE9+ 1Owpo3YDi0IE6rwGryjkU2yA31xSdtbqAqc9JM17ZkMYSRCbv24K18fk3t9AvOSQ7mdM s3z7/kHjPRmW6jbF/E9wC9DVMiSWfyc4OWDvZI5e0PrB7TfLXfQULiTdlISCSkZ0lHro L2sw== 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=FUNBU7kw7u4/270uoC50G2VLxbYf9B5lkkkni8ASFoQ=; b=oGmXyRZ7To1gmESl4Bi4vtQ0eRCTLRtp+g6tmyePg0Nokr5sIZNesNoedHBi3FPCyD Mml5aQhxVl/v30sulB3gvFxnNt6vxWXJbmnmYEsTOJ1eLf45SyNuHIGhzaFfJV+AV/lf dj07COlaruFkMqogjdwnXmcuBGrB9Ff5Ycge+mP+wyHDc8RspfSnT14RclKdbg83532l VJ997eJalMUyIFTmJMmixJxWI++lIwIlZcX7xPG7KLvazsO5stGgbqcskHNcOQ7x0KUT tAyL0xE5Z5ZNYCDqOk0Z0GGLX6mXIe0YLPBFEvIyRkt7vE7E/pokJ+p2UfVQZxZuJBFB 7gnQ== X-Gm-Message-State: APjAAAVb1OLUAix3p+DOXteU79eD8aYTZJycKRRThUOFmkg3mIC4WJnn nF/U5Q64K5MfcOJh+0Ao7MR61hunOUpE+Hl3/Sg= X-Google-Smtp-Source: APXvYqyBZzIOOlEqRFxNeQIga6Mf4N6Gx0tnOsUWA0mpKdnoPAww2I5fDxljAOIJApSsUhAZtiN0iiwklso6yC15jyc= X-Received: by 2002:ab0:45e7:: with SMTP id u94mr15184537uau.47.1566235360901; Mon, 19 Aug 2019 10:22:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 19 Aug 2019 10:22:30 -0700 Message-ID: To: Jeffrey Yasskin Cc: Ted Hardie , wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000523c4e05907b96b4" Archived-At: Subject: Re: [Wpack] Approach to use for web packaging media types X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 17:22:46 -0000 --000000000000523c4e05907b96b4 Content-Type: text/plain; charset="UTF-8" Hi Jeffrey, On Fri, Aug 16, 2019 at 3:17 PM Jeffrey Yasskin wrote: > [...] > > These specifications haven't been accepted into an IETF WG yet, so I > hadn't asked for provisional registration, but since we've already deployed > some code using application/signed-exchange and are implementing support > for application/webbundle, Ted Hardie suggested we get your advice on how > to handle the media types. > You can submit a provisional registration for those names. All you need is the name(s) you want to reserve and contact information, which I believe could be the chairs or yourself, as the working group pleases, and stick that in an email to media-types@iana.org. I don't think they need formal review or approval beyond that (according to RFC 6838 Section 5.2.1); IANA just does it. Later, when the working group has a complete registration to standardize, that would replace the provisional stub and move it to a regular registration. Since it's coming from a working group, IESG approval of the document completes the registration process, though you're welcome to request a review of the formal registration from us at any time in the process. If you decide to change the names or otherwise abandon the provisional registrations, please let us know so they're not left dangling. -MSK --000000000000523c4e05907b96b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeffrey,

On Fri, Aug 16, 2019 at 3:= 17 PM Jeffrey Yasskin <jyasskin@g= oogle.com> wrote:
[...]

These specifications haven= 9;t been accepted into an IETF WG yet, so I hadn't asked for provisiona= l registration, but since we've already deployed some code using applic= ation/signed-exchange and are implementing support for application/webbundl= e, Ted Hardie suggested we get your advice on how to handle the media types= .

You can submit a provisional = registration for those names.=C2=A0 All you need is the name(s) you want to= reserve and contact information, which I believe could be the chairs or yo= urself, as the working group pleases, and stick that in an email to media-types@iana.org.=C2=A0 I don'= t think they need formal review or approval beyond that (according to RFC 6= 838 Section 5.2.1); IANA just does it.

Later, when the working group= has a complete registration to standardize, that would replace the provisi= onal stub and move it to a regular registration.=C2=A0 Since it's comin= g from a working group, IESG approval of the document completes the registr= ation process, though you're welcome to request a review of the formal = registration from us at any time in the process.=C2=A0 If you decide to cha= nge the names or otherwise abandon the provisional registrations, please le= t us know so they're not left dangling.

-M= SK
--000000000000523c4e05907b96b4-- From nobody Mon Aug 19 11:09: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 201E1120043 for ; Mon, 19 Aug 2019 11:09:11 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hJZPhfPngUC for ; Mon, 19 Aug 2019 11:09:08 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB19D12001E for ; Mon, 19 Aug 2019 11:09:08 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id p12so3885270iog.5 for ; Mon, 19 Aug 2019 11:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jdc9oumZPRj/Nld+icl8LlaptJMIP97Dj5BQRc9Tk2c=; b=TuYCa/vMRrVZ5oROLHC1zKKxo3IJL0ryNoHV+X5rB0kMYSQ9PT0ZU+g4VDOE4YDEf6 jF7KLgicf7Pep3GBi+oAZRrgdg0Mka+GNy43bAxQQTiKwn7SWnq1I4X7+P7Kny4SAH6G 4PoZq09E6iZIxtYph+OHXpRWwv1vcfd3vOeJoNHX931IQKbFUykspqLav8DDpHd6adPN Q1fV0W4jvK/ge6zed+RorjQpH03kFotya3SZ9sWtz7zAr4Gvt0RUH/8F2VnPBv7UlMwf HxvrtDIwaWovvYKmimq4wB7wJLCR0y+ni2w89gyNNrDvbWYF4RPmkysCsCv7FYxr/mT2 KQLA== 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=jdc9oumZPRj/Nld+icl8LlaptJMIP97Dj5BQRc9Tk2c=; b=ZXqy5zcNPvsLv3RcbB6KvGY7NTGv0X8uQHrDnJ5aPhn87Y5WZYcMdzm1D/AQqOS2J+ sVWHoVIGm7wFjWLvwaWBFgOAaL9k/Co264gyt+z8e3fwLMkx5wTVzTK9Inf7Af5ZcSZa M5qVQHxBs+vhWKx4lfXkZUWHsTC8wseHVT9IG6fN7d8GNK0zaCCWLx0ZfA+CI/ZMoI57 QtO4Dje14PT5s7R0KOnq3RbGJaH2tasdsMHvBT+BgiJpbt4GDNxhz7LvhBepocmgN6Qw ZttYkL8v+xIROm/bph9jDjxuTA5FbhV2P2Mm6oQlN1ip/pWUilE2t5ltkgwGYOwJ+jGs PmSw== X-Gm-Message-State: APjAAAVci/uUcIKD2xiJdRAlEsy/NeiZSuWUjXGVrHEh6RffTD8szeHm 6w9DiPIC2yATvSfnFFqEQuWhFNrJGi13zysWJ+c= X-Google-Smtp-Source: APXvYqw9veOzdjUuxSW1RQpoabQ1ZoTC439c3CWyOrXaKIrNdA++fZsw0RLQMJBwA05rqvMnQgyvDkj5BDbOFsIiZtQ= X-Received: by 2002:a5e:c113:: with SMTP id v19mr24377013iol.219.1566238147902; Mon, 19 Aug 2019 11:09:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Mon, 19 Aug 2019 11:08:41 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Jeffrey Yasskin , Ted Hardie , wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000708f5e05907c3cba" Archived-At: Subject: Re: [Wpack] Approach to use for web packaging media types X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 18:09:11 -0000 --000000000000708f5e05907c3cba Content-Type: text/plain; charset="UTF-8" Hi Murray, Your message below refers to a working group, but an IETF working group has not yet been formed. Do you mean the W3C interest group, or can Jeffrey go ahead with the process you outlined on the strength of the upcoming BoF? Ted On Mon, Aug 19, 2019 at 10:22 AM Murray S. Kucherawy wrote: > Hi Jeffrey, > > On Fri, Aug 16, 2019 at 3:17 PM Jeffrey Yasskin > wrote: > >> [...] >> >> These specifications haven't been accepted into an IETF WG yet, so I >> hadn't asked for provisional registration, but since we've already deployed >> some code using application/signed-exchange and are implementing support >> for application/webbundle, Ted Hardie suggested we get your advice on how >> to handle the media types.. >> > > You can submit a provisional registration for those names. All you need > is the name(s) you want to reserve and contact information, which I believe > could be the chairs or yourself, as the working group pleases, and stick > that in an email to media-types@iana.org. I don't think they need formal > review or approval beyond that (according to RFC 6838 Section 5.2.1); IANA > just does it. > > Later, when the working group has a complete registration to standardize, > that would replace the provisional stub and move it to a regular > registration. Since it's coming from a working group, IESG approval of the > document completes the registration process, though you're welcome to > request a review of the formal registration from us at any time in the > process. If you decide to change the names or otherwise abandon the > provisional registrations, please let us know so they're not left dangling. > > -MSK > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack > --000000000000708f5e05907c3cba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Murray,

Your message belo= w refers to a working group, but an IETF working group has not yet been for= med.=C2=A0 Do you mean the W3C interest group, or can Jeffrey go ahead with= the process you outlined on the strength of the upcoming BoF?
Ted

On Mon, Aug 19, 2019 at 10:22 AM Murray S. Kucher= awy <superuser@gmail.com> = wrote:
Hi Jeffrey,

On Fri, Aug 16, 2019 at 3:17 PM Je= ffrey Yasskin <= jyasskin@google.com> wrote:
[...]

These specifications = haven't been accepted into an IETF WG yet, so I hadn't asked for pr= ovisional registration, but since we've already deployed some code usin= g application/signed-exchange and are implementing support for application/= webbundle, Ted Hardie suggested we get your advice on how to handle the med= ia types..

You can submit a pro= visional registration for those names.=C2=A0 All you need is the name(s) yo= u want to reserve and contact information, which I believe could be the cha= irs or yourself, as the working group pleases, and stick that in an email t= o media-types@ian= a.org.=C2=A0 I don't think they need formal review or approval beyo= nd that (according to RFC 6838 Section 5.2.1); IANA just does it.

La= ter, when the working group has a complete registration to standardize, tha= t would replace the provisional stub and move it to a regular registration.= =C2=A0 Since it's coming from a working group, IESG approval of the doc= ument completes the registration process, though you're welcome to requ= est a review of the formal registration from us at any time in the process.= =C2=A0 If you decide to change the names or otherwise abandon the provision= al registrations, please let us know so they're not left dangling.
<= /div>

-MSK
_______________________________________________
Wpack mailing list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo/wpack
--000000000000708f5e05907c3cba-- From nobody Mon Aug 19 15:59: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 47636120088 for ; Mon, 19 Aug 2019 15:59:05 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rRLy89NFgkd for ; Mon, 19 Aug 2019 15:59:03 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 E88A012008C for ; Mon, 19 Aug 2019 15:59:02 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id 34so1271273uar.8 for ; Mon, 19 Aug 2019 15:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dTAz758MpSiKkYZunxsZp4fJpKMdG5yoMId6fE7WyHE=; b=gLgQSE3s5hPpeuZxOOJDrL+/c2uoQ6c1XHdM/iDIoL2fTsxooKHEyfE71g3Vq7lFb8 QS0brBFn9qWQ8iKIVTkgOFnkgC40yPwRI4M4ZRuZ78axVvR4jJiGvaTxzNKq/cG+za4G eF50or3ViW5luHY2xt49IvpK1nqTwxN4Ij4GDlfiirpzJCqtQ5hmMxTaNgj6t0i6LfhH GgBIrl8D0569VdkutN6JZGU69fkOaX952wNIiADpXw6W+zmcnpsNhVLVGmt1Xx005heI ibfNlOw8sgH7ELi56Fll4eWLtJ73D/7cVBJ17BPcFMgsFciHKhoRXeMBfYDTXxIKCaCX bnpA== 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=dTAz758MpSiKkYZunxsZp4fJpKMdG5yoMId6fE7WyHE=; b=LLdXTpQ6/kvAZ3qAAiotwdDkNpE86MXWVdd+WrxgutPE4GtKVKhmhOPlOXP75gUDee 4l/y9XmTb3xQcweodXul/lRyWx7CLQcsb76bJyUDNFdsUNhWWUUHjDBDYpV4haDAGU1v JhQqeOQoy23nmfRAvdzu6+9btzfAxtn6B/bsa5GQvmNZfkEkIUrVO8jGkeVvJuWmnZMF v+275jVXbIkdZzBPYlNKO4kGQJChJJJksBARfEXSJEjOhnyjoXiqC73uPP5J5q1mbqXi /ZPh/j/ovRSgkp5pZsiVGjuT9apcad3XWBGNDEql7QMA/cnyuTfuGDmj1Dm0ZCv95H3r l3Tg== X-Gm-Message-State: APjAAAVW25OgGjsrquh0N3+ai4veQB24So/+fRDTc+kf9RfixMf6dOS+ k2uOdluC8380Fu7kxCIwSeI48PWvKyAZG8xOjUI= X-Google-Smtp-Source: APXvYqwIdGKUjuD9AaOlvi9dLjna0UidY71ffJo5o72pNcQyVOq+hb7XqQVt/OugRXXcfStTQFqne1CnNs/Q1zLvLuY= X-Received: by 2002:ab0:7812:: with SMTP id x18mr15554696uaq.67.1566255541823; Mon, 19 Aug 2019 15:59:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 19 Aug 2019 15:58:50 -0700 Message-ID: To: Ted Hardie Cc: Jeffrey Yasskin , Ted Hardie , wpack@ietf.org Content-Type: multipart/alternative; boundary="00000000000032ae3805908049a2" Archived-At: Subject: Re: [Wpack] Approach to use for web packaging media types X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 22:59:05 -0000 --00000000000032ae3805908049a2 Content-Type: text/plain; charset="UTF-8" Sorry, I saw "wpack@ietf.org" and assumed there was a working group. I think Jeffrey can make the provisional registration solo, especially given the apparent momentum. But again, if things change, please deregister or update it as appropriate. -MSK On Mon, Aug 19, 2019 at 11:09 AM Ted Hardie wrote: > Hi Murray, > > Your message below refers to a working group, but an IETF working group > has not yet been formed. Do you mean the W3C interest group, or can > Jeffrey go ahead with the process you outlined on the strength of the > upcoming BoF? > > Ted > > On Mon, Aug 19, 2019 at 10:22 AM Murray S. Kucherawy > wrote: > >> Hi Jeffrey, >> >> On Fri, Aug 16, 2019 at 3:17 PM Jeffrey Yasskin >> wrote: >> >>> [...] >>> >>> These specifications haven't been accepted into an IETF WG yet, so I >>> hadn't asked for provisional registration, but since we've already deployed >>> some code using application/signed-exchange and are implementing support >>> for application/webbundle, Ted Hardie suggested we get your advice on how >>> to handle the media types.. >>> >> >> You can submit a provisional registration for those names. All you need >> is the name(s) you want to reserve and contact information, which I believe >> could be the chairs or yourself, as the working group pleases, and stick >> that in an email to media-types@iana.org. I don't think they need >> formal review or approval beyond that (according to RFC 6838 Section >> 5.2.1); IANA just does it. >> >> Later, when the working group has a complete registration to standardize, >> that would replace the provisional stub and move it to a regular >> registration. Since it's coming from a working group, IESG approval of the >> document completes the registration process, though you're welcome to >> request a review of the formal registration from us at any time in the >> process. If you decide to change the names or otherwise abandon the >> provisional registrations, please let us know so they're not left dangling. >> >> -MSK >> _______________________________________________ >> Wpack mailing list >> Wpack@ietf.org >> https://www.ietf.org/mailman/listinfo/wpack >> > --00000000000032ae3805908049a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, I saw "= wpack@ietf.org" and assumed there was a working group.
<= br>
I think Jeffrey can make the provisional registration solo, e= specially given the apparent momentum.=C2=A0 But again, if things change, p= lease deregister or update it as appropriate.

-MSK=

On Mon, Aug 19, 2019 at 11:09 AM Ted Hardie <ted.ietf@gmail.com> wrote:
Hi Murray,

Your message below refers to a working group, but an = IETF working group has not yet been formed.=C2=A0 Do you mean the W3C inter= est group, or can Jeffrey go ahead with the process you outlined on the str= ength of the upcoming BoF?

Ted

=
On Mon, Au= g 19, 2019 at 10:22 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
Hi Jeffrey,

On Fri, Aug 16, 2019 at 3:17 PM Jeffrey Yasskin <= ;jyasskin@google.c= om> wrote:
[...]

These specifications haven't been = accepted into an IETF WG yet, so I hadn't asked for provisional registr= ation, but since we've already deployed some code using application/sig= ned-exchange and are implementing support for application/webbundle, Ted Ha= rdie suggested we get your advice on how to handle the media types..
<= /div>

You can submit a provisional registra= tion for those names.=C2=A0 All you need is the name(s) you want to reserve= and contact information, which I believe could be the chairs or yourself, = as the working group pleases, and stick that in an email to media-types@iana.org.=C2=A0 = I don't think they need formal review or approval beyond that (accordin= g to RFC 6838 Section 5.2.1); IANA just does it.

Later, when the wor= king group has a complete registration to standardize, that would replace t= he provisional stub and move it to a regular registration.=C2=A0 Since it&#= 39;s coming from a working group, IESG approval of the document completes t= he registration process, though you're welcome to request a review of t= he formal registration from us at any time in the process.=C2=A0 If you dec= ide to change the names or otherwise abandon the provisional registrations,= please let us know so they're not left dangling.

-MSK
_______________________________________________
Wpack mailing list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo/wpack
--00000000000032ae3805908049a2-- From nobody Mon Aug 19 16:27: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 7D71012008C for ; Mon, 19 Aug 2019 16:27:07 -0700 (PDT) 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 EqV-eAZvyS-8 for ; Mon, 19 Aug 2019 16:27:05 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 F34D1120024 for ; Mon, 19 Aug 2019 16:27:04 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id b29so2642506lfq.1 for ; Mon, 19 Aug 2019 16:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vAmJJ/ml3qPNXb9+Ac9ajRPUDFr8Ka0MKcf04u8/zu4=; b=K64I2eHPvkzgGgoIj5X3zQovGCUNHCKMbKkxNA3Lyiy4U87icM/+aMKxiyretbiXUJ cf3D1BPa5/5aiBeEoZRIXuklUz1NsaIfLhlvBsvL64OmiOqF8PS8debS4PiVpECCsFr7 WbGHUiZykAe7BoxVHIp61lI1kzVpNZyBXYjo/8XnwQraRbFvOBOU+J4NxYCMpPHT+tUB dh6hi3FdHJtgHccNygxsiM3A/w4BzpX/fePI5YUOFuLxQps+PtcfubAZjkuKg9y1ug1G j184GTen1yKUxW7HZY2Z+r/p7nyYDQVce9JteBonRCEL2/+GyHC2iyMyNaPlI8Ezexv2 lNWg== 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=vAmJJ/ml3qPNXb9+Ac9ajRPUDFr8Ka0MKcf04u8/zu4=; b=CY59Eb+9d39mn9js6QUKfThPPBI6BhaQ/MdNFfesSMhvA8f8+ZUF5/N+0yUh7fBB1U SNFqTRqno3hl04N/B/YnokXMEM//BarZHtgy1au9wvclvCIg+X5yv/sN8QH6m2B7A4iO HfXwu3d40UQYvkTfvXioazlce0J71jn4bKMpqq1vEMeVcg2XRVKPpxSI9ubW0FC5WYdE 3q0c2dEWp3+jbExEwf9AjNl4IDlQYskvHanRGL/n1im6a2l3Rsu0++ls2JPvoeFpg1FX hkplGVkzt4Yi34xOiDy/Y1vhdIE2ONrMzZT4ScuuqO4wqhlGTxAZO7ljqFE8S2YdR3zJ dzOg== X-Gm-Message-State: APjAAAUpd784NXGYyRWZajd80nsYvShErdTk/2k7MK+56BbX5DclCDL3 IqmMnayuYGPmu1XcbtVzPZ8e1bPN2GV17jNUZFiT7w== X-Google-Smtp-Source: APXvYqzE10ZC9w0NNzlTygLjtube2f/EKuzmYt1b0xhZ/y9ReuSSZVFf/OFjPeWBOhUUW18laqz9avpnkyqjnsNCAHw= X-Received: by 2002:ac2:51a3:: with SMTP id f3mr12931270lfk.94.1566257222841; Mon, 19 Aug 2019 16:27:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Mon, 19 Aug 2019 16:26:49 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Ted Hardie , Ted Hardie , wpack@ietf.org Content-Type: multipart/alternative; boundary="00000000000065432f059080adff" Archived-At: Subject: Re: [Wpack] Approach to use for web packaging media types X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 23:27:07 -0000 --00000000000065432f059080adff Content-Type: text/plain; charset="UTF-8" Thanks! I'll provisionally register these media types then. Jeffrey On Mon, Aug 19, 2019 at 3:59 PM Murray S. Kucherawy wrote: > Sorry, I saw "wpack@ietf.org" and assumed there was a working group. > > I think Jeffrey can make the provisional registration solo, especially > given the apparent momentum. But again, if things change, please > deregister or update it as appropriate. > > -MSK > > On Mon, Aug 19, 2019 at 11:09 AM Ted Hardie wrote: > >> Hi Murray, >> >> Your message below refers to a working group, but an IETF working group >> has not yet been formed. Do you mean the W3C interest group, or can >> Jeffrey go ahead with the process you outlined on the strength of the >> upcoming BoF? >> >> Ted >> >> On Mon, Aug 19, 2019 at 10:22 AM Murray S. Kucherawy >> wrote: >> >>> Hi Jeffrey, >>> >>> On Fri, Aug 16, 2019 at 3:17 PM Jeffrey Yasskin >>> wrote: >>> >>>> [...] >>>> >>>> These specifications haven't been accepted into an IETF WG yet, so I >>>> hadn't asked for provisional registration, but since we've already deployed >>>> some code using application/signed-exchange and are implementing support >>>> for application/webbundle, Ted Hardie suggested we get your advice on how >>>> to handle the media types.. >>>> >>> >>> You can submit a provisional registration for those names. All you need >>> is the name(s) you want to reserve and contact information, which I believe >>> could be the chairs or yourself, as the working group pleases, and stick >>> that in an email to media-types@iana.org. I don't think they need >>> formal review or approval beyond that (according to RFC 6838 Section >>> 5.2.1); IANA just does it. >>> >>> Later, when the working group has a complete registration to >>> standardize, that would replace the provisional stub and move it to a >>> regular registration. Since it's coming from a working group, IESG >>> approval of the document completes the registration process, though you're >>> welcome to request a review of the formal registration from us at any time >>> in the process. If you decide to change the names or otherwise abandon the >>> provisional registrations, please let us know so they're not left dangling. >>> >>> -MSK >>> _______________________________________________ >>> Wpack mailing list >>> Wpack@ietf.org >>> https://www.ietf.org/mailman/listinfo/wpack >>> >> --00000000000065432f059080adff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks! I'll provisionally register these media types = then.

Jeffrey

=
On Mon, Aug 19, 2019 at 3:59 PM Murra= y S. Kucherawy <superuser@gmail.c= om> wrote:
Sorry, I saw "wpack@ietf.org" and assumed there was a workin= g group.

I think Jeffrey can make the provisional = registration solo, especially given the apparent momentum.=C2=A0 But again,= if things change, please deregister or update it as appropriate.

-MSK

On Mon, Aug 19, 2019 at 11:09 AM Ted Hardie &= lt;ted.ietf@gmail.c= om> wrote:
Hi Murray,

Your message be= low refers to a working group, but an IETF working group has not yet been f= ormed.=C2=A0 Do you mean the W3C interest group, or can Jeffrey go ahead wi= th the process you outlined on the strength of the upcoming BoF?
=
Ted

On Mon, Aug 19, 2019 at 10:22 AM Murray S. Ku= cherawy <superu= ser@gmail.com> wrote:
Hi Jeffrey,

On Fri, Aug 1= 6, 2019 at 3:17 PM Jeffrey Yasskin <jyasskin@google.com> wrote:
[...]

= These specifications haven't been accepted into an IETF WG yet, so I ha= dn't asked for provisional registration, but since we've already de= ployed some code using application/signed-exchange and are implementing sup= port for application/webbundle, Ted Hardie suggested we get your advice on = how to handle the media types..

You can submit a provisional registration for those names.=C2=A0 All you n= eed is the name(s) you want to reserve and contact information, which I bel= ieve could be the chairs or yourself, as the working group pleases, and sti= ck that in an email to media-types@iana.org.=C2=A0 I don't think they need formal re= view or approval beyond that (according to RFC 6838 Section 5.2.1); IANA ju= st does it.

Later, when the working group has a complete registratio= n to standardize, that would replace the provisional stub and move it to a = regular registration.=C2=A0 Since it's coming from a working group, IES= G approval of the document completes the registration process, though you&#= 39;re welcome to request a review of the formal registration from us at any= time in the process.=C2=A0 If you decide to change the names or otherwise = abandon the provisional registrations, please let us know so they're no= t left dangling.

-MSK
_______________________________________________
Wpack mailing list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo/wpack
--00000000000065432f059080adff--