From nobody Sun Feb 2 07:54:33 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C598312003F; Sun, 2 Feb 2020 07:54:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: wpack-chairs@ietf.org, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158065886877.11289.7788966809321945998.idtracker@ietfa.amsl.com> Date: Sun, 02 Feb 2020 07:54:28 -0800 Archived-At: Subject: [Wpack] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-i?= =?utf-8?q?etf-wpack-00-04=3A_=28with_COMMENT=29?= X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 15:54:29 -0000 Éric Vyncke has entered the following ballot position for charter-ietf-wpack-00-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-wpack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Interesting work to be done. As I have some non-blocking comments/questions (see below), I have entered a 'no objection' but this is mostly a 'yes'. Suggest to replace 'Three examples to" by 'Three use cases to" in the first goal. Unsure whether "Constraints on how clients load the formats" can be parsed as a goal. No mention of interaction with other IETF WG. May I assume that WPACK also encompass the naming / retrieval of those web package ? Nit " above properties. * Support", insert a CRLF ? Nit: should "DRM" be expanded ? From nobody Mon Feb 3 20:42:05 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAEC1200F9; Mon, 3 Feb 2020 20:42:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach via Datatracker To: "The IESG" Cc: wpack-chairs@ietf.org, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <158079132198.28494.4442064153308104629.idtracker@ietfa.amsl.com> Date: Mon, 03 Feb 2020 20:42:01 -0800 Archived-At: Subject: [Wpack] Adam Roach's No Objection on charter-ietf-wpack-00-04: (with COMMENT) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 04:42:02 -0000 Adam Roach has entered the following ballot position for charter-ietf-wpack-00-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-wpack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to external review, but I think there are some issues we need to see addressed prior to approval. > * A low likelihood that the new format increases centralization or power > imbalances on the web. I'm glad to see this in the charter. I would really like to see this bullet point expanded to more clearly cover the three different categories of specific concerns described in section 4.1 of draft-iab-escape-report (or, alternately, cite that document for further detail). > Note that consensus is required both for changes to the current protocol > mechanisms and retention of current mechanisms I think this presumes a bit too much. Although the adoption of the initial candidate documents may be highly likely, this text clearly implies that their adoption is a fait accompli. > In particular, because > something is in the initial document set (consisting of > draft-yasskin-wpack-use-cases, draft-yasskin-wpack-bundled-exchanges, and > draft-yasskin-http-origin-signed-responses) I also think we really need clearly-defined milestones here. Particularly, seeing draft-yasskin-wpack-use-cases in the list of candidate documents, I believe we need to clearly indicate whether the WG intends to publish a use case document, especially in the context of the IESG statement at https://ietf.org/about/groups/iesg/statements/support-documents/ If the intention *is* to publish the document, indicating that such is the case (and why) will help during IESG review of such a document. From nobody Tue Feb 4 05:23:57 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF3412010C; Tue, 4 Feb 2020 05:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=NeHNQnqy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q2ZYcpTg 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 ZtVzxj2RBI-2; Tue, 4 Feb 2020 05:23:51 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0521200A4; Tue, 4 Feb 2020 05:23:47 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D707021EAF; Tue, 4 Feb 2020 08:23:46 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Tue, 04 Feb 2020 08:23:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm2; bh=1Z0mr iFzxgnj0AgsjDHkhC37ngI99nOWbec2mky+6GA=; b=NeHNQnqySKJoPd5Yp1Qgp pA9HOL4dDTc5Z5e6jAjS/3mHFMR6vHppaLfpDKbgTkFEOyEdkVkoorXgW0RdcU71 iog7uUOSH+0S7iomyuWSHQbBrGa4u/7b9z3LW0GntppAbNt/KTmFLEEWLMYLNghz S1hMpXonnGUqa6oxDwsv4ZHnDNiR2Vcek4YXd+q0SelEZMjVL0hmx685hKc5JxY0 XLebZ8hQ5+ZvLvK1YbtAebKJc6GH0K3mpHpEBPPC7xmazlVB9tYxSACUxZSYzTUR yVMtfQamagL7yK8V4feg+B+GBFLRaRmDusw1iP6tkSl8QMFrORewLKSMw+aka1EC Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=1Z0mriFzxgnj0AgsjDHkhC37ngI99nOWbec2mky+6 GA=; b=q2ZYcpTgvGHU+0P77SGINRU5RtH7T7dh9dAbskZNSqWqgKyMCELIjlcOd QLffMhrOpvaNfTHbaY8yTaPN3dG3NGS+QXYkts/1fahprL3KCYnKLtyN/Bffqrf/ ZRpTyxAGFI0NH9Q3DVUYSfjM62Yxe7lE4AabLFlhAStyRcLPhhxEg/ByG2wzeBy3 PVjYZhkfeNGSWgz/xL7HWIuZuuzwfaLPziK8WZqYIp74uyrRz7v9d6byC4BfojEG anFl4bC3vMOxGv8Y5ZbNI4v8+uHpQux82sZp3YYBXI6jlaVVJWeWnBGrYxrrL3Bk cRbH5h6LClRetrkr1xtT1vRcDlILA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrgeelgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuffhomhgrihhnpehnihhtrggsohhvvghprhhophgvrhhtihgvshdrshhuphhp ohhrthenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe grrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A18D5660069; Tue, 4 Feb 2020 08:23:46 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <8eaca83b-88b0-4968-aa74-5e9c779f1165@www.fastmail.com> In-Reply-To: <158065886877.11289.7788966809321945998.idtracker@ietfa.amsl.com> References: <158065886877.11289.7788966809321945998.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2020 13:23:16 +0000 From: "Alexey Melnikov" To: "Eric Vyncke (evyncke)" , "The IESG" Cc: wpack@ietf.org, wpack-chairs@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Wpack] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-i?= =?utf-8?q?etf-wpack-00-04=3A_=28with_COMMENT=29?= X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 13:23:53 -0000 Hi =C3=89ric, Thank you for your comments. My replies below: On Sun, Feb 2, 2020, at 3:54 PM, =C3=89ric Vyncke via Datatracker wrote:= > =C3=89ric Vyncke has entered the following ballot position for >=20 > Interesting work to be done. As I have some non-blocking comments/ques= tions > (see below), I have entered a 'no objection' but this is mostly a 'yes= '. >=20 > Suggest to replace 'Three examples to" by 'Three use cases to" in the = first > goal. Changed, thank you. > Unsure whether "Constraints on how clients load the formats" can be pa= rsed as a > goal. Good point. I need to check Jeffrey what was intended here. > No mention of interaction with other IETF WG. Good point. I added "The WPACK working group will work closely with the = HTTPbis working group." =20 > May I assume that WPACK also encompass the naming / retrieval of those= web > package ? No. I think this is standard HTTP (which is HTTPBIS WG) or some peer-to-= peer mechanism. >=20 > Nit " above properties. * Support", insert a CRLF ? Done. > Nit: should "DRM" be expanded ? I added expanded version just in case. Best Regards, Alexey From nobody Tue Feb 4 05:36:40 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AC91200F5; Tue, 4 Feb 2020 05:36:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: wpack-chairs@ietf.org, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <158082339622.15820.6318276487462018950.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2020 05:36:36 -0800 Archived-At: Subject: [Wpack] Magnus Westerlund's No Objection on charter-ietf-wpack-00-04: (with COMMENT) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 13:36:37 -0000 Magnus Westerlund has entered the following ballot position for charter-ietf-wpack-00-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-wpack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have some questions. Does there exist an easy way to resolve the clash between this primary and non-goal? Primary goal: * The ability to create an unsigned snapshot of a web page without the cooperation of its publisher. Non-goal: * A way to distribute the private portions of a website. For example, WPACK might define a way to distribute a messaging application but wouldn't define a way to distribute individual messages without a direct connection to the messaging application's origin server. So the issue I wonder over, is that if I as a user decide to snapshot a web-page that contains some server-side dynamically generated resources. To my understanding that would result in that dynamically user specific generated content would be captured. How does this relate to the above non-goal. Or are these two different usages of the targeted solution. One to allow snap shoting what one actually provided, and another a configuration for distributing a part of a web-site? The above thought lead to the question: Is it at all possible to prevent a user from sharing their private content if using this mechanism? Will the packager be able to determine what is private and what is not so that the user can select between a snapshot and sharing the general part of a web-site? Next: Relationship to Other WGs and SDOs WPACK will work with the W3C and WHATWG to identify the existing security and privacy models for the web, and to ensure those SDOs can define how this format is used by web browsers. Will calling WHATWG an SDO create any issues for the IETF? WhatWG is to my knowledge an Industry Forum. From nobody Tue Feb 4 07:17:15 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B781A120020; Tue, 4 Feb 2020 07:17:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: alexey.melnikov@isode.com, wpack@ietf.org, wpack-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158082943371.15730.8644189062042620298.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2020 07:17:13 -0800 Archived-At: Subject: [Wpack] wpack - New Meeting Session Request for IETF 107 X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 15:17:14 -0000 A new meeting session request has just been submitted by Alexey Melnikov, a ART Area Director. --------------------------------------------------------- Working Group Name: Web Packaging Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 150 Conflicts to Avoid: Technology Overlap: httpbis quic dispatch secdispatch saag tls acme People who must be present: Sean Turner Alexey Melnikov Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Feb 4 09:47:30 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAE0120274 for ; Tue, 4 Feb 2020 09:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 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.25, 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 wqs_YVuwnIFJ for ; Tue, 4 Feb 2020 09:47:26 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913EF120152 for ; Tue, 4 Feb 2020 09:47:26 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id v195so18754705qkb.11 for ; Tue, 04 Feb 2020 09:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sIbMez4kSt7AiFyViA2DGi4u8frr7KOiY6rzU1Oex6Q=; b=mTnefisBwUo7ti5Nr1SljTB/IJH+xeInXI1e9FBrnBAaFGIzgEOwvYG32bValjPjuj i3OENdSqv0+6RxLd/ytFUi7mHpA8Hr+GdzYnGaWBvaF9lNsreCwz7xKKhsap/gENPMGt Xm2eqHf9xQRl9GA3NFl/INNuzasg+beX4/LQk= 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=sIbMez4kSt7AiFyViA2DGi4u8frr7KOiY6rzU1Oex6Q=; b=a5S0uiNJ0TDiHhqHx6fHywIUeTWWtfuepgcP8prdAK4NI7VvBvgZAJJZMRgw/soEOS axZZvQj04ME5/CtFOzY7OwVyx+8tp+ia68xNWFUhhgccFJaF0aF3C5D6xGvsNFOqLKM3 yeQMJI0Yc0TMB1S4qVvbDUkLqbaqrkiSXelhR6vCCVqRRF5Hp52awDFkvGf7BNXZoTNk mLevC/1/ibNfMQXkbVmXswGMa0+H2aBcxHm3soRCTGlZXBOVT2pQzaYDX4hy4JH5HZvd 4jdotXizbWcrnS4Lhh2VE6f5sPp9B9lHDY7DDMZ8lgNfmkgxsw/idp5TnkE5Z5lU3Ede yUbw== X-Gm-Message-State: APjAAAVfydGUVLdyTAcKW1gi36m3lYUBQq/DPZxAuxTCn7vsER73M8YK ENnTmQNhbi3nK8AslLR9aT7WDLAfSxwWgPdyEp68fg== X-Google-Smtp-Source: APXvYqxiYUtuwPxUH8UKjg0kDQlQrL19uETQTHNecx5pODzVZl+Xhi0D7wQCXWQ/6hPIT5Mhy8CKY69hgUMqpsbZuqM= X-Received: by 2002:ae9:c318:: with SMTP id n24mr30639183qkg.38.1580838445189; Tue, 04 Feb 2020 09:47:25 -0800 (PST) MIME-Version: 1.0 References: <158079132198.28494.4442064153308104629.idtracker@ietfa.amsl.com> In-Reply-To: <158079132198.28494.4442064153308104629.idtracker@ietfa.amsl.com> From: Jeffrey Yasskin Date: Tue, 4 Feb 2020 09:47:12 -0800 Message-ID: To: Adam Roach Cc: The IESG , wpack@ietf.org, wpack-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000f962eb059dc3a14a" Archived-At: Subject: Re: [Wpack] Adam Roach's No Objection on charter-ietf-wpack-00-04: (with COMMENT) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 17:47:29 -0000 --000000000000f962eb059dc3a14a Content-Type: text/plain; charset="UTF-8" On Mon, Feb 3, 2020 at 8:42 PM Adam Roach via Datatracker wrote: > Adam Roach has entered the following ballot position for > charter-ietf-wpack-00-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-wpack/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > No objection to external review, but I think there are some issues we need > to > see addressed prior to approval. > > > > * A low likelihood that the new format increases centralization or power > > imbalances on the web. > > I'm glad to see this in the charter. I would really like to see this bullet > point expanded to more clearly cover the three different categories of > specific concerns described in section 4.1 of draft-iab-escape-report (or, > alternately, cite that document for further detail). > That sounds fine to me. > Note that consensus is required both for changes to the current protocol > > mechanisms and retention of current mechanisms > > I think this presumes a bit too much. Although the adoption of the initial > candidate documents may be highly likely, this text clearly implies that > their adoption is a fait accompli. > I copied this text blindly from the QUIC charter, and I'd be happy with any version that allows the WG to adopt and start working on some documents before having consensus that what's in them is correct. > In particular, because > > something is in the initial document set (consisting of > > draft-yasskin-wpack-use-cases, draft-yasskin-wpack-bundled-exchanges, and > > draft-yasskin-http-origin-signed-responses) > > I also think we really need clearly-defined milestones here. Particularly, > seeing draft-yasskin-wpack-use-cases in the list of candidate documents, > I believe we need to clearly indicate whether the WG intends to publish > a use case document, especially in the context of the IESG statement at > https://ietf.org/about/groups/iesg/statements/support-documents/ > If the intention *is* to publish the document, indicating that such > is the case (and why) will help during IESG review of such a document. > I find that IESG statement convincing and would not push to publish the use cases as an RFC. The IESG statement doesn't explicitly say whether WGs should adopt this kind of support document at all, but I'd appreciate getting it under WG control instead of having to guess about consensus myself. Thanks, Jeffrey --000000000000f962eb059dc3a14a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Feb 3, 2020 at 8:42 PM Adam Roach= via Datatracker <noreply@ietf.org> wrote:
Adam Roach has entered the following ballot positi= on for
charter-ietf-wpack-00-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-wp= ack/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

No objection to external review, but I think there are some issues we need = to
see addressed prior to approval.


> * A low likelihood that the new format increases centralization or pow= er
> imbalances on the web.

I'm glad to see this in the charter. I would really like to see this bu= llet
point expanded to more clearly cover the three different categories of
specific concerns described in section 4.1 of draft-iab-escape-report (or,<= br> alternately, cite that document for further detail).
<= br>
That sounds fine to me.

> Note that consensus is required both for changes to the current protoc= ol
> mechanisms and retention of current mechanisms

I think this presumes a bit too much. Although the adoption of the initial<= br> candidate documents may be highly likely, this text clearly implies that their adoption is a fait accompli.

I co= pied this text blindly from the QUIC charter, and I'd be happy with any= version that allows the WG to adopt and start working on some documents be= fore having consensus that what's in them is correct.

> In particular, because
> something is in the initial document set (consisting of
> draft-yasskin-wpack-use-cases, draft-yasskin-wpack-bundled-exchanges, = and
> draft-yasskin-http-origin-signed-responses)

I also think we really need clearly-defined milestones here. Particularly,<= br> seeing draft-yasskin-wpack-use-cases in the list of candidate documents, I believe we need to clearly indicate whether the WG intends to publish
a use case document, especially in the context of the IESG statement at
https://ietf.org/about/groups/iesg/s= tatements/support-documents/
If the intention *is* to publish the document, indicating that such
is the case (and why) will help during IESG review of such a document.
<= /blockquote>

I find that IESG statement convincing and w= ould not push to publish the use cases as an RFC. The IESG statement doesn&= #39;t explicitly say whether WGs should adopt this kind of support document= at all, but I'd appreciate getting it under WG control instead of havi= ng to guess about consensus myself.

Thanks,
<= div>Jeffrey
--000000000000f962eb059dc3a14a-- From nobody Tue Feb 4 10:35:00 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA85812020A for ; Tue, 4 Feb 2020 10:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 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.25, 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 AVMIfLkzOwDQ for ; Tue, 4 Feb 2020 10:34:56 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 B5E05120170 for ; Tue, 4 Feb 2020 10:34:55 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id j5so15105515qtq.9 for ; Tue, 04 Feb 2020 10:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=viBMrlKeM7f/Gih/sZzfxITTfEIYhIOFzT0P2fdmE5A=; b=d0ikMDWojFk2COllycYgmOGp6gV1d8k1TpK3tedhHU3BwV/dvALXm5WNWt3tjz4E6F KlGiz3xMw3008El4u72B3dz0BdjgVLbJmF44FwqLe0vyFr09eCYobBM768pOHBaRyIIV 2/MTUY1bUGn8jVIYCAa2u9/qpY9C1gqhugsdM= 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=viBMrlKeM7f/Gih/sZzfxITTfEIYhIOFzT0P2fdmE5A=; b=uaRIcGsqGgLwr+rhW9OEXwQgvg3r5bmsv4ivUoAsXGupPvND8O29b9R2zyMRliAnZR IOw11KPEANQV7clQAegnsxvzsqW8rQ8WslrcYCl35ckpxEkAnVAQU5Il9ItIsWYAi2+4 8X5xOFGjxOtGs0tW+pXrzVuwIGqFqBf6WzhV3nIG3eJks3Rj2OPGVWQmhqx2j0BaBR7v +iJygWl5UReksyO8pSDMVvTeWc+slPvpP8WHiUrSUBK/GeyLnvVWduI1N9wkb8qUtS2K Pf1mygwWr4zqLXqzWI3bdk4WVfuPU0lY0DPojDL87eo4f0OgPDVUba4wcUVagu0ox6mA B4JQ== X-Gm-Message-State: APjAAAUr9KLBCYl5PCcdPIgdDnjudFykcJQfm7WWUdHzHOEPmTEmfp3W 121o5hj7vnfyxhOgE0tVfBGz38bo1dSuX/R/rHtM9Q== X-Google-Smtp-Source: APXvYqz4kbezZvIf7w0CkqmDPMS+QsIuu+1wvJZJMAR0gLhjUm/9iOjpygzrrxoPLLV0KrQFyYGJp9nq6vQE3oip/sM= X-Received: by 2002:ac8:138b:: with SMTP id h11mr29490639qtj.153.1580841294426; Tue, 04 Feb 2020 10:34:54 -0800 (PST) MIME-Version: 1.0 References: <158065886877.11289.7788966809321945998.idtracker@ietfa.amsl.com> <8eaca83b-88b0-4968-aa74-5e9c779f1165@www.fastmail.com> In-Reply-To: <8eaca83b-88b0-4968-aa74-5e9c779f1165@www.fastmail.com> From: Jeffrey Yasskin Date: Tue, 4 Feb 2020 10:34:42 -0800 Message-ID: To: Alexey Melnikov Cc: "Eric Vyncke (evyncke)" , The IESG , wpack@ietf.org, wpack-chairs@ietf.org, Martin Thomson Content-Type: multipart/alternative; boundary="000000000000cd78e1059dc44b9a" Archived-At: Subject: Re: [Wpack] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-i?= =?utf-8?q?etf-wpack-00-04=3A_=28with_COMMENT=29?= X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 18:34:58 -0000 --000000000000cd78e1059dc44b9a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2020 at 5:24 AM Alexey Melnikov wrote: > On Sun, Feb 2, 2020, at 3:54 PM, =C3=89ric Vyncke via Datatracker wrote: > > Unsure whether "Constraints on how clients load the formats" can be > parsed as a > > goal. > > Good point. I need to check Jeffrey what was intended here. > This comes from a discussion at the BoF over my initial non-goal of "Defining the details of how web browsers load the formats and interact with any protocols we define here." The minutes record: - MT: one thing missing is one clear articilation of he constraints people running this should operate in order to maintain guaratnees. agre= e with dkg. we are setting a new bar that require meeting a brand new set = of requirements. that relates to things that mnot, jeffrey havem mentioned. along with personalisation. we should capture these and do an anaylsis t= o ensure that we can get this right. ... - ben schwarz: i agree with MT. 'out of scope for how browsers load format' -- no, we should list constraints. this could actually be a vict= ory for privacy over HTTPs e.g. if servers push bundles this may have better privacy properties. I think Martin was suggesting that the IETF-side specifications should include requirements on the client that ensure the security properties we want, even though we wouldn't include detailed algorithms for how a web browser builds a Document object out of the formats. I don't have strong opinions on how to word that goal. Jeffrey --000000000000cd78e1059dc44b9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2020 at 5:24 AM Alexey Mel= nikov <aamelnikov@fastmail.fm<= /a>> wrote:
On Sun, Feb 2, 2020, at 3:54 PM, =C3=89ric Vyncke= via Datatracker wrote:
> Unsure whether "Constraints on how cli= ents load the formats" can be parsed as a
> goal.

Good point. I need to check Jeffrey what was intended here.

This comes from a discussion at the BoF over my initia= l non-goal of "Defining the details of how web browsers load the forma= ts and interact with any protocols we define here." The minutes record= :
  • MT: one thing missing is one clear articilation of he c= onstraints people running this should operate in order to maintain guaratne= es. agree with dkg. we are setting a new bar that require meeting a brand n= ew set of requirements. that relates to things that mnot, jeffrey havem men= tioned. along with personalisation. we should capture these and do an anayl= sis to ensure that we can get this right. ...
  • ben schwarz: i agree = with MT. 'out of scope for how browsers load format' -- no, we shou= ld list constraints. this could actually be a victory for privacy over HTTP= s e.g. if servers push bundles this may have better privacy properties.
    =
I think Martin was suggesting that the IETF-side speci= fications should include requirements on the client that ensure the securit= y properties we want, even though we wouldn't include detailed algorith= ms for how a web browser builds a Document object out of the formats. I don= 't have strong opinions on how to word that goal.

<= div>Jeffrey=C2=A0
--000000000000cd78e1059dc44b9a-- From nobody Tue Feb 4 11:38:46 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E7D12022D; Tue, 4 Feb 2020 11:38:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: wpack@ietf.org, wpack-chairs@ietf.org, sean@sn3rd.com, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158084512473.15698.7753904203363892001.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2020 11:38:44 -0800 Archived-At: Subject: [Wpack] wpack - Update to a Meeting Session Request for IETF 107 X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 19:38:45 -0000 An update to a meeting session request has just been submitted by Sean Turner, a Chair of the wpack working group. --------------------------------------------------------- Working Group Name: Web Packaging Area Name: Applications and Real-Time Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 150 Conflicts to Avoid: Chair Conflict: tls mls quic Technology Overlap: httpbis dispatch secdispatch saag acme People who must be present: Sean Turner Alexey Melnikov Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Feb 4 13:25:31 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FB5120170 for ; Tue, 4 Feb 2020 13:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 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.25, 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 yZc9H33OdFVZ for ; Tue, 4 Feb 2020 13:25:28 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15EE112012E for ; Tue, 4 Feb 2020 13:25:28 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id w25so19580703qki.3 for ; Tue, 04 Feb 2020 13:25:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XHyc4LvwgvYsrdaZE7yO95tK/wgZRQAYA0LWJEveTEE=; b=N+i9VyULPBO89pFW9vev693U1jntHjmK/PmVI4QxPLkBXqwTk8aq3MN3v3/dGpc5DA fNrnXSubVAkk2aB8lHVPrP4s47QSrbvZ6i2zv9rAkIbFOktYb6Xa0EhEKG9EVE5ZafsO zkpHyez3qNl0FPJpEtb4UUI8ZqbY3BUSMeE3c= 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=XHyc4LvwgvYsrdaZE7yO95tK/wgZRQAYA0LWJEveTEE=; b=kKzaiwLKrA/8JoRQVMJWQ/wBVCNKgbL30nR3CvAkiZLJeRACggd8fp0PVLtTcPhkDD g+6lZw6mwRcqOy6KIx4JgkBCfEXOQeyyB7Fes6RUk7K07yeriCAgq/2Ywhk29DEwtF4s KHz+KeRyMCiZBduwOxcXwkfNCAu7Wy08kYU55C+Gw+gN0bRTTxPJNUFG6Ob798xY+KEs ZItZkzhlFeMma3mwTKNo4zjLOQi5+cQ0XS3myAar1Q8ocnGj/k95UqGuzsdhXsi/3XVC bZVDQ9HEbf1ZPuaJJpY6Qol8BrooGhTYL80u9OEry142ZyfO48T26kveEv5CfG1ibjys WikQ== X-Gm-Message-State: APjAAAUYseVxiUNYX85wXFGaq4ooG4k/9AiydoEA/i2zrARuQnLpkwOe muujjPkbsrjKe5r2KW3Gq16etjRQAQh490cxwMWNWw== X-Google-Smtp-Source: APXvYqwS60AMvdb15TWfjJbBex5JyGnotzc5btABrSg1omld9rlrKp5FtdFB1jSjfseHJJ7OUQZ5/QB43L+mHzLff3c= X-Received: by 2002:a37:e505:: with SMTP id e5mr27984088qkg.324.1580851526839; Tue, 04 Feb 2020 13:25:26 -0800 (PST) MIME-Version: 1.0 References: <158082339622.15820.6318276487462018950.idtracker@ietfa.amsl.com> In-Reply-To: <158082339622.15820.6318276487462018950.idtracker@ietfa.amsl.com> From: Jeffrey Yasskin Date: Tue, 4 Feb 2020 13:25:13 -0800 Message-ID: To: Magnus Westerlund Cc: The IESG , wpack@ietf.org, wpack-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000b3a96b059dc6adf2" Archived-At: Subject: Re: [Wpack] Magnus Westerlund's No Objection on charter-ietf-wpack-00-04: (with COMMENT) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 21:25:30 -0000 --000000000000b3a96b059dc6adf2 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 5:36 AM Magnus Westerlund via Datatracker < noreply@ietf.org> wrote: > Magnus Westerlund has entered the following ballot position for > charter-ietf-wpack-00-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-wpack/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have some questions. > > Does there exist an easy way to resolve the clash between this primary and > non-goal? Primary goal: * The ability to create an unsigned snapshot of a > web > page without the cooperation of its publisher. > > Non-goal: > * A way to distribute the private portions of a website. For example, WPACK > might define a way to distribute a messaging application but wouldn't > define a way to distribute individual messages without a direct connection > to > the messaging application's origin server. > > So the issue I wonder over, is that if I as a user decide to snapshot a > web-page that contains some server-side dynamically generated resources. > To my > understanding that would result in that dynamically user specific generated > content would be captured. How does this relate to the above non-goal. Or > are > these two different usages of the targeted solution. One to allow snap > shoting > what one actually provided, and another a configuration for distributing a > part > of a web-site? > > The above thought lead to the question: Is it at all possible to prevent a > user > from sharing their private content if using this mechanism? Will the > packager > be able to determine what is private and what is not so that the user can > select between a snapshot and sharing the general part of a web-site? > These are talking about the difference between 1) unsigned content, 2) signed content, and 3) signed and encrypted content, where I wanted to say that (3) is out of scope. It's safe to share unsigned personalized content with the permission of whoever's data it is. It's not safe for the recipient to use signed personalized content even with the permission of the owner of the data. So, the wording of "A way to distribute the private portions of a website." is missing an indication that it's about distribution when signed as the website or in a way that the client will trust that it's authentically from the website. I don't know a way for the client to automatically identify what's private or not without cooperation from the website. If the website does provide a package, I think it'd make sense for clients to give their users the ability to save either the website's package or an unsigned snapshot of what they're currently looking at. Next: > > Relationship to Other WGs and SDOs > > WPACK will work with the W3C and WHATWG to identify the existing security > and > privacy models for the web, and to ensure those SDOs can define how this > format > is used by web browsers. > > Will calling WHATWG an SDO create any issues for the IETF? WhatWG is to my > knowledge an Industry Forum. > Do you have a definition of "SDO" handy? https://www.w3.org/2019/04/WHATWG-W3C-MOU.html describes the WHATWG as "a community of people interested in evolving the web", discusses the W3C endorsing the WHATWG's Living Standards, and distinguishes both groups from "de jure standards organizations". Does that help at all? Jeffrey --000000000000b3a96b059dc6adf2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Magnus Westerlund has entered the followin= g ballot position for
charter-ietf-wpack-00-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-wp= ack/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have some questions.

Does there exist an easy way to resolve the clash between this primary and<= br> non-goal? Primary goal: * The ability to create an unsigned snapshot of a w= eb
page without the cooperation of its publisher.

Non-goal:
* A way to distribute the private portions of a website. For example, WPACK=
might define a way to distribute a messaging application but wouldn't define a way to distribute individual messages without a direct connection = to
the messaging application's origin server.

So the issue I wonder over, is that if I as a user decide to snapshot a
web-page that contains some server-side dynamically generated resources. To= my
understanding that would result in that dynamically user specific generated=
content would be captured. How does this relate to the above non-goal. Or a= re
these two different usages of the targeted solution. One to allow snap shot= ing
what one actually provided, and another a configuration for distributing a = part
of a web-site?

The above thought lead to the question: Is it at all possible to prevent a = user
from sharing their private content if using this mechanism? Will the packag= er
be able to determine what is private and what is not so that the user can select between a snapshot and sharing the general part of a web-site?

These are talking about the difference betwe= en 1) unsigned content, 2) signed content, and 3) signed and encrypted cont= ent, where I wanted to say that (3) is out of scope. It's safe to share= unsigned personalized content with the permission of whoever's data it= is. It's not safe for the recipient to use signed personalized content= even with the permission of the owner of the data. So, the wording of &quo= t;A way to distribute the private portions of a website." is missing a= n indication that it's about distribution when signed as the website or= in a way that the client will trust that it's authentically from the w= ebsite.

I don't know a way for the client to a= utomatically identify what's private or not without cooperation from th= e website. If the website does provide a package, I think it'd make sen= se for clients to give their users the ability to save either the website&#= 39;s package or an unsigned snapshot of what they're currently looking = at.

Next:

Relationship to Other WGs and SDOs

WPACK will work with the W3C and WHATWG to identify the existing security a= nd
privacy models for the web, and to ensure those SDOs can define how this fo= rmat
is used by web browsers.

Will calling WHATWG an SDO create any issues for the IETF? WhatWG is to my<= br> knowledge an Industry Forum.

Do you hav= e a definition of "SDO" handy?=C2=A0https://www.w3.org/2019/04/WHATWG-W3C-MOU.htm= l=C2=A0describes the WHATWG as "a community of people interested i= n evolving the web", discusses the W3C endorsing the WHATWG's=C2= =A0Living Standards, and distinguishes both groups from "de jure stand= ards organizations". Does that help at all?

J= effrey
--000000000000b3a96b059dc6adf2-- From nobody Tue Feb 4 20:35:25 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AA21200B1; Tue, 4 Feb 2020 20:35:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: wpack-chairs@ietf.org, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <158087731973.15693.2828361095219090722.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2020 20:35:19 -0800 Archived-At: Subject: [Wpack] Barry Leiba's No Objection on charter-ietf-wpack-00-05: (with COMMENT) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 04:35:20 -0000 Barry Leiba has entered the following ballot position for charter-ietf-wpack-00-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-wpack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * A low likelihood that the new format increases centralization or power imbalances on the web. I don’t have much confidence that this can reasonably be achieved in reality, but I have no objection to having it listed as a goal. In particular, because something is in the initial document set (consisting of does not imply I suggest that the complaint about this part could be best addressed by not listing the drafts in the charter and by saying it this way: NEW In particular, because something is in an initial working group draft does not imply END From nobody Wed Feb 5 01:18:02 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3F4120288; Wed, 5 Feb 2020 01:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=VVhy3CGW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=n1KEV0EH 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 wFVoP_jKBBPZ; Wed, 5 Feb 2020 01:17:57 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC69E120129; Wed, 5 Feb 2020 01:17:57 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id ADB9B2151C; Wed, 5 Feb 2020 04:17:54 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 05 Feb 2020 04:17:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=0 SRFwacLtUuZNt/u2Sxjt0x2WQIFNuVfcKL86yAlshc=; b=VVhy3CGWtcPjZg1wL wxYdpdNHNUcY8TEb2S+DQYzLxPS8ytr8eJDxcZh4Y0RTSQgWgdII7SoOKQc2gM6l zAJMM572HQtYKCoIvi5CuaTzPWAjZnZ2Bhh8Xz3liyQrAlIVd6ag2m9LmbYYgpwl zte82BLGOvNs+z8RFoQOX9tdRNSLFAUkfbQFigV1Fr/BgolF65TmHFzMtmb76++X Q+9m6L72JhxGcsBYTPyytWGDFAXez8wPRgiXNObrptMzltHuWERuP3lYkCur48td VQwBe+wsh3SCyiwU4kVQkgxqInoHdK7ScZ6JsYcnS18c47wYzlvShBTEz218Ro+O FEz8Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm2; bh=0SRFwacLtUuZNt/u2Sxjt0x2WQIFNuVfcKL86yAls hc=; b=n1KEV0EH9sWohnkxpsTIyCqnHUyMDEsrGZpgY/TbrP1EBsuPkRGA2ZL9+ ZzYmDwGHgY8yEFU1k5pA3+64n8JExBY6u6J58d69EwsLsuKO8m5cNdxKP72KXLYJ ahjA0WFrLKLcFDzQc1Q2TVuhtQL4vKZKc0aW22jl3SKmMc9FBYjoCSIabwVYQeLv 6mhgvvGVB+kSkDTdjZkFQc/mRWCvQWpxDozWs+81L9XqSxRvyr/+Vhz7U7SA90Dr zCJOrKpTzS38E36woOkfUUZLFOSTviTT/9ZZDqwy5sGKWFrKpH4n3TPECQWTj2XQ V7hUqEZJEAkyLLz2ZmXC+TvaIW9HA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrhedugddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe iffedrohhrghdpmhhnohhtrdhnvghtnecukfhppedutdegrddufedvrddvvdekrddutdei necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnoh htsehmnhhothdrnhgvth X-ME-Proxy: Received: from [100.72.36.122] (unknown [104.132.228.106]) by mail.messagingengine.com (Postfix) with ESMTPA id 79B53328005D; Wed, 5 Feb 2020 04:17:53 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Mark Nottingham In-Reply-To: <158082339622.15820.6318276487462018950.idtracker@ietfa.amsl.com> Date: Wed, 5 Feb 2020 10:17:52 +0100 Cc: The IESG , wpack@ietf.org, wpack-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0D1A45E0-6C1E-47E4-B7D2-C09AE5D8060B@mnot.net> References: <158082339622.15820.6318276487462018950.idtracker@ietfa.amsl.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Wpack] Magnus Westerlund's No Objection on charter-ietf-wpack-00-04: (with COMMENT) 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, 05 Feb 2020 09:18:00 -0000 > On 4 Feb 2020, at 2:36 pm, Magnus Westerlund via Datatracker = wrote: >=20 > Relationship to Other WGs and SDOs >=20 > WPACK will work with the W3C and WHATWG to identify the existing = security and > privacy models for the web, and to ensure those SDOs can define how = this format > is used by web browsers. >=20 > Will calling WHATWG an SDO create any issues for the IETF? WhatWG is = to my > knowledge an Industry Forum. Liaison to the W3C hat semi-on -- See . Effectively, W3C = has ceded development of several core specifications to WHATWG.=20 Of course, some people have a very strict definition of what an SDO is = -- but the IETF as well as the W3C would fail many of those tests. I'd = just admit that they're effectively an SDO, even if some folks don't = like how they're set up. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Feb 5 02:39:07 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EBD1207FE; Wed, 5 Feb 2020 02:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=T6vKffU5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3dyjQvFB 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 ZTUiwCP6H2v3; Wed, 5 Feb 2020 02:39:02 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181ED12029C; Wed, 5 Feb 2020 02:39:02 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 183B122007; Wed, 5 Feb 2020 05:39:01 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Wed, 05 Feb 2020 05:39:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=3N54j8PYHNrgOgUSZ/dKx8N9m8VraIF TjRNwOiwGR+o=; b=T6vKffU5RebqX0PKFfSzx8fCECKso24Tn+pGa0U1LZ3eOwv /wUnqy3984u5rEhv/XVYyQrK9KnqhRe45QoH1QB9J8AQTEOA7q3xogVfLy+vuM/5 nP1S+d4Ssh7IEGB4eL0Zbh3z8MJOsxhaS63bA4qNZNLyGkFUlgUsCFzdcIGW38nZ EVfrKmIwMaVdqMTTZulA1skYuUHYwFGHkI5t/X9C933aTs3yyZ327p6Mk63ng3Nn pjoTM6C6I07grdQoxqxCveeLLBZ+TEGc22/+scNeCmTzLsi6okobouEIcsVqvMEa EjygozRSD3seg+tZZrH5iXto8HW+1+WbKlrOn0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=3N54j8 PYHNrgOgUSZ/dKx8N9m8VraIFTjRNwOiwGR+o=; b=3dyjQvFBlyrXsjMhDda+AO 1mmapjvx4PZoxojNRveZm4O6B8Gj71GjrfhzVWB+Vjea/xs9uO4iMSWnwBpfU5gx +CoH99Gec/b8Wts0aKsG5QkJh1m7rfJf5wRCW+qD1RXDG3eYYyxauwR0TG8dm03k GUnlODEXB1nk8VIoeL0HPalbRf9jNbE9ULUg0Fq7Q3ayrzMdzP6aXQickjMylQyR +o7zOqbcnSH+DZRXlUz12NXysqds21kUC2VHYcxH5BUezf0TyDoIN2F0iBeJWa1n VNtqe7Yk5JYTuW45I62KuRSmtbGzweRnbkjk4a0m7q3c2NsxwYGyjhtRus74d9XA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrhedugddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr rghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A8B5F660065; Wed, 5 Feb 2020 05:39:00 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <266fe27e-f4a9-406f-97d4-a3acbda508b4@www.fastmail.com> In-Reply-To: References: <158065886877.11289.7788966809321945998.idtracker@ietfa.amsl.com> <8eaca83b-88b0-4968-aa74-5e9c779f1165@www.fastmail.com> Date: Wed, 05 Feb 2020 10:38:22 +0000 From: "Alexey Melnikov" To: "Jeffrey Yasskin" Cc: "Eric Vyncke (evyncke)" , "The IESG" , wpack@ietf.org, wpack-chairs@ietf.org, "Martin Thomson" Content-Type: multipart/alternative; boundary=504ec8f038de4864a0683b2c15b3ae34 Archived-At: Subject: Re: [Wpack] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-i?= =?utf-8?q?etf-wpack-00-04=3A_=28with_COMMENT=29?= 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, 05 Feb 2020 10:39:05 -0000 --504ec8f038de4864a0683b2c15b3ae34 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2020, at 6:34 PM, Jeffrey Yasskin wrote: > On Tue, Feb 4, 2020 at 5:24 AM Alexey Melnikov wrote: >> On Sun, Feb 2, 2020, at 3:54 PM, =C3=89ric Vyncke via Datatracker wro= te: >> > Unsure whether "Constraints on how clients load the formats" can be= parsed as a >> > goal. >>=20 >> Good point. I need to check Jeffrey what was intended here. >=20 > This comes from a discussion at the BoF over my initial non-goal of "D= efining the details of how web browsers load the formats and interact wi= th any protocols we define here." The minutes record: > * MT: one thing missing is one clear articilation of he constraints p= eople running this should operate in order to maintain guaratnees. agree= with dkg. we are setting a new bar that require meeting a brand new set= of requirements. that relates to things that mnot, jeffrey havem mentio= ned. along with personalisation. we should capture these and do an anayl= sis to ensure that we can get this right. ... > * ben schwarz: i agree with MT. 'out of scope for how browsers load f= ormat' -- no, we should list constraints. this could actually be a victo= ry for privacy over HTTPs e.g. if servers push bundles this may have bet= ter privacy properties. > I think Martin was suggesting that the IETF-side specifications should= include requirements on the client that ensure the security properties = we want, even though we wouldn't include detailed algorithms for how a w= eb browser builds a Document object out of the formats. I don't have str= ong opinions on how to word that goal. Ok. I changed the sentence to read: "Specifying constraints on how clients load the formats without describi= ng specific loading algorithm to help achieve the above goals." If you think that further changes are needed, please let me know. Best Regards, Alexey --504ec8f038de4864a0683b2c15b3ae34 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, Fe= b 4, 2020, at 6:34 PM, Jeffrey Yasskin wrote:
On Tue, Feb 4, 2020= at 5:24 AM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
On Sun, Feb 2, 2020, at 3:54 PM, =C3=89ric Vyncke via Datatr= acker wrote:
> Unsure whether "Constraints on how clien= ts load the formats" can be parsed as a
> goal.

Good point. I need to check Jeffrey what was inten= ded here.

This comes from a di= scussion at the BoF over my initial non-goal of "Defining the details of= how web browsers load the formats and interact with any protocols we de= fine here." The minutes record:
  • MT: one thing miss= ing is one clear articilation of he constraints people running this shou= ld operate in order to maintain guaratnees. agree with dkg. we are setti= ng a new bar that require meeting a brand new set of requirements. that = relates to things that mnot, jeffrey havem mentioned. along with persona= lisation. we should capture these and do an anaylsis to ensure that we c= an get this right. ...
  • ben schwarz: i agree with MT. 'out of= scope for how browsers load format' -- no, we should list constraints. = this could actually be a victory for privacy over HTTPs e.g. if servers = push bundles this may have better privacy properties.
I think Martin was suggesting that the IETF-side specifications sh= ould include requirements on the client that ensure the security propert= ies we want, even though we wouldn't include detailed algorithms for how= a web browser builds a Document object out of the formats. I don't have= strong opinions on how to word that goal.

Ok. I changed the sentence to read:

"Specifying constraints on how clients load the format= s without describing specific loading algorithm to help achieve the abov= e goals."

If you think that further changes= are needed, please let me know.

Best Regar= ds,
Alexey

--504ec8f038de4864a0683b2c15b3ae34-- From nobody Wed Feb 5 02:53:37 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DB1120090 for ; Wed, 5 Feb 2020 02:53:36 -0800 (PST) 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=VfqGnUm+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vNzZ2TmE 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 RBRLTRr7bTMh for ; Wed, 5 Feb 2020 02:53:32 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2AB1120019 for ; Wed, 5 Feb 2020 02:53:32 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 668D53E9 for ; Wed, 5 Feb 2020 05:53:31 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 05 Feb 2020 05:53:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=qiEO4cTAe4RP6TRJoDt725KrI9I53Kz rIvASnsltK6A=; b=VfqGnUm+3183tpomliDHjsPD6t2wLPzmCQrAkUP+5Cgz7j+ WfJDE4RJBpumsh17LTXm/OzXtsOhZ9wcre1WCW+fb1tUQQYkxKOuH4nx7KEiglG5 ItoMNyqGmlbpcK8RDsm6hQcsvoqpap0kLFXdIzl4kNGAdwtzEHf1iqUljy3l3wcl yg7E3oZd+xIDFnfk31roGYxJP4/bgkL5oNESE9lsKx8AATPxERfk23sOij07LTxL RZ0KIBnEI/Jjai9elWNcDDU+czFhtAYRq3EMmIF01HxRds5XV6Iu3Pz277lj+icA Hq4dX+OhJupG9cza6c18iFFTYPhq0520SNs0q7Q== 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=fm2; bh=qiEO4c TAe4RP6TRJoDt725KrI9I53KzrIvASnsltK6A=; b=vNzZ2TmEhaIGB+rGABekXQ pGlmpuuFAGKRpHVaOS5I14iS2/BzKb7IeQbpZoT52FCXoiZ9Zv7Ao+yV9tKS3sje 84Ztbi3ryXpkfv9uFmpJoNiOzPt9pfeQV5PHyYFIbJTZDqiOX2Rz3YECYYdVdObR /XT7Zp/JgHAdcHrnxZjr3Rby5Zs78tgUQs+u5u8w5Ni1Vme+dueYhYfEfhm0sqCl v8Vc+yzjm20oBPM2AdX+4TYqRW6c1xwgfmZVpmhshU5mfxviCwbgMyJDhuTHxE7p C/0VPgq5LuqhcslpwQxZMb3QEaUMFyMNANbmQDWzg5uUHFPybTa1GMwNPt+dAm8A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrhedugddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B6908E00A2; Wed, 5 Feb 2020 05:53:30 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <072c9a87-2c78-4fbe-8699-bf3793c83dd8@www.fastmail.com> In-Reply-To: <266fe27e-f4a9-406f-97d4-a3acbda508b4@www.fastmail.com> References: <158065886877.11289.7788966809321945998.idtracker@ietfa.amsl.com> <8eaca83b-88b0-4968-aa74-5e9c779f1165@www.fastmail.com> <266fe27e-f4a9-406f-97d4-a3acbda508b4@www.fastmail.com> Date: Wed, 05 Feb 2020 11:53:09 +0100 From: "Martin Thomson" To: wpack@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-i?= =?utf-8?q?etf-wpack-00-04=3A_=28with_COMMENT=29?= 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, 05 Feb 2020 10:53:36 -0000 On Wed, Feb 5, 2020, at 11:38, Alexey Melnikov wrote: > "Specifying constraints on how clients load the formats without > describing specific loading algorithm to help achieve the above goals." Though it says what we want, I found this particularly hard to parse. From nobody Wed Feb 5 05:23:26 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E6A120805; Wed, 5 Feb 2020 05:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=cUKUEvYR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xMua3lVx 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 yYjhw8Xf0mWr; Wed, 5 Feb 2020 05:23:21 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3BCC120026; Wed, 5 Feb 2020 05:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16697; q=dns/txt; s=iport; t=1580909000; x=1582118600; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=y0PItSVqAPMm80TM9NmZCkIdI7dQWAjnam9xG3DwBDc=; b=cUKUEvYRtYV3QtjfcYOCV6zeT640HyPwgK3Hb4w4ShMj+26MEvmrR/L2 rb8M7IDm9YHyUZSpCmb682ZQGHYoT5pWv2DEVNpZvt5HJWhb1/itB59fg KiP76DLshnyVWzp9FUpwlt3SHoczUPxP0iKoNgxE4PjddueWV+qzFg4WP M=; IronPort-PHdr: =?us-ascii?q?9a23=3AgMduhxLpyK3x7P1/LNmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEDlPfjhbCESF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BpCADhwDpe/4QNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBJS9QBWxYIAQLKoQVYYJlA4p5gl+TMIRiglIDVAkBAQEMAQE?= =?us-ascii?q?tAgEBhEACF4IjJDgTAgMNAQEEAQEBAgEFBG2FNwyFZgEBAQECARIRChMBATc?= =?us-ascii?q?BBAsCAQYCDgMDAQIBJwMCAgIwFAYDCAIEAQ0FIoMEAYF9TQMOIAGPY5BmAoE?= =?us-ascii?q?5iFIQdYEygn8BAQWFFBiCDAmBOIwiGoFBP4ERJyCBTn4+hGsWgloygiyNUIM?= =?us-ascii?q?HhWKZMQqCOoxWOokzG4JIiA+ESItqg0mLGZsfAgQCBAUCDgEBBYFpIoFYcBU?= =?us-ascii?q?7KgGCQVAYDY4dOIM7ilN0gSmNJgEB?= X-IronPort-AV: E=Sophos;i="5.70,405,1574121600"; d="scan'208,217";a="717133404" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Feb 2020 13:23:19 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 015DNJrc026365 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2020 13:23:19 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 5 Feb 2020 07:23:18 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 5 Feb 2020 07:23:18 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 5 Feb 2020 07:23:18 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KSfFPUQzrfoeCb5ZiqQ6WuBWXPj6Q168KWfP2cscrMeEjK/yEKhL0VjXkwaxivm1Gh42uCM1L1cfsGgmdxt5S5I2GbHJZ25x/zgb8zFT6y6/UB08qYr6x7pHRlcPUi8ocoYHsuw2e29tI9kavzdDlodzPViSlgynHVLbv3q+w6R95WiPUJqYzMMFPd9CSwrVaHXVEShqYe3UUhKYJlnMEDXYOdUJJX1yIVUcwwKCwQVpQq4LAXeCNmfT8MflQXJPnqZF2RPzlAdRWBhijqK1BUoXful3MIn+/0XtCO64iIl5U7LQIC7gJ1jicKW/B6A0/OHUawSt9MN2rlVWSzid4Q== 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=y0PItSVqAPMm80TM9NmZCkIdI7dQWAjnam9xG3DwBDc=; b=VAFVW82LE74emmtggcapxaB68uTOS97LYuuhYuC5MBA3fyg+tkKHLLdBHVThlGpWHLAGF58I5ddXuhtv3ymy+oKVG/di6SzxfwmUAJ5CwStnOowItkE7WJpdM5iVdM4GTlYLAm/H9q1IT4khXfyGHPknQBazIDU6zO70egWPoRoM2zea8SAhZjPxh9FsxijUtWUFKaXmAQMoeM8MRVw5mzkOe6mepR22qZvlqlTi7IuMalLQ9GG4k84AzTrpK4G3Pqj071GbHTZd4/evY7I4P4IMCUPMMRZU8FcVUW5d/atzqvHqFcDFphNEvuk+RRhPfbLWqiqSIW0R6TH+tjCHjA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y0PItSVqAPMm80TM9NmZCkIdI7dQWAjnam9xG3DwBDc=; b=xMua3lVxVCWmcmvDiDdkGS3/LEmvlj8NG+wcL3CrFch+l6ZpCaHg/N4LPNxnSJDTUV90maSdICP34LKdx9YmUnXT/G3XBW9CSgwDzR3mcBjZ4QcQ+KdfK9GDgyfeVRGjrXtr3ZJD0huM1poHA3ud9J67GImwIzontMnpH3IvK40= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (10.175.88.141) by DM5PR11MB1435.namprd11.prod.outlook.com (10.172.35.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Wed, 5 Feb 2020 13:23:17 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca%3]) with mapi id 15.20.2707.020; Wed, 5 Feb 2020 13:23:17 +0000 From: "Eric Vyncke (evyncke)" To: Alexey Melnikov , Jeffrey Yasskin CC: The IESG , "wpack@ietf.org" , "wpack-chairs@ietf.org" , Martin Thomson Thread-Topic: =?utf-8?B?W1dwYWNrXSDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gY2hhcnRl?= =?utf-8?Q?r-ietf-wpack-00-04:_(with_COMMENT)?= Thread-Index: AQHV215wBpq7eiqaWE6LQsieUoAw36gLXMoAgAENPwCAAD7WAA== Date: Wed, 5 Feb 2020 13:23:17 +0000 Message-ID: References: <158065886877.11289.7788966809321945998.idtracker@ietfa.amsl.com> <8eaca83b-88b0-4968-aa74-5e9c779f1165@www.fastmail.com> <266fe27e-f4a9-406f-97d4-a3acbda508b4@www.fastmail.com> In-Reply-To: <266fe27e-f4a9-406f-97d4-a3acbda508b4@www.fastmail.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:44f0:1250:65aa:af0:1eba:333b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a8990c99-0161-40bd-6835-08d7aa3e8fe0 x-ms-traffictypediagnostic: DM5PR11MB1435: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(376002)(396003)(136003)(346002)(189003)(199004)(6486002)(110136005)(316002)(6512007)(54906003)(8936002)(4326008)(81156014)(81166006)(36756003)(2906002)(66574012)(5660300002)(66476007)(71200400001)(6506007)(53546011)(33656002)(64756008)(86362001)(66946007)(66446008)(2616005)(186003)(66556008)(91956017)(76116006)(224303003)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1435; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zPVdYJrJSxnQBjRWDCW1jTFHAb3jAh46hnED7n2lmMesiYFTF2WreeD0PDVKjosNPd8OQrCTvbEcr2G1nAiVgt43cEQlxlbMQ3Cvbb4/ITi6cp6Jo5VbmSVzrZPl8O293TJ82FnBilPcQWgwTN1n1oWfhvG9b2VQzy/eY0wcHl9nQMFYdVvTV4Dz0s31Gf41pQCKgddpWWG0yJPq0dsE1eCF+dhTiUH+/AuNRr+ePthoevFONkmVTvgz7HTIkCyS3YnhIt28Y0eg+D2ap5YribHjGfKoghCoT1lJFfC0NbDI7upcQYKaWGfmZp41u8Rki/snC+54qezVsOdKfZknnKeEESgfAVCtKLjPMF92uhR3Qtx+KpmceIIhgcNIdFx/IXi85hfaw78PR/MrYY+HDMvqaZgvQPFNzT3bNQomA1m/esQDgEjWFys6af/cPHwe x-ms-exchange-antispam-messagedata: Ozo7xItYUAhxjjE94lPzWkoL+8+lfd+saFQBXE5AtcWMb34Ygvacp7FB5UeB45uRJ9Kh2SdDRJTc0OY00Z4Xf/1ltceQCTOvKz8VSvaCwSoTODOKh1QQIHt22MTu+1+DPs5J59sz1UG5JxAyhzY3bXsMWPt40N0hnFkwS5+w7rgClkMZGcjArP8SvybYUvQNJhbZLUupDkrD2f3T7gnxTw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DEB006C9B742452FAD7163C82D98AA24ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a8990c99-0161-40bd-6835-08d7aa3e8fe0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 13:23:17.3368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PXdl36qec9XoBJxyOv2OdXmpPQEswdit3AoDQQiX32ZJEiBefYkjlLqpfJ7wWKroUdW6BBpBlRdthV/EM+xo1w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1435 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Wpack] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-i?= =?utf-8?q?etf-wpack-00-04=3A_=28with_COMMENT=29?= 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, 05 Feb 2020 13:23:23 -0000 --_000_DEB006C9B742452FAD7163C82D98AA24ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 77u/VGhhbmsgeW91IEFsZXhleSwgdGhpcyBpcyBleGFjdGx5IHdoYXQgSSB3YXMgbG9va2luZyBm b3I6IHRoaXMgc2VudGVuY2Ugbm93IHBhcnNlcyBhcyBhIGdvYWwg8J+YiQ0KDQotw6lyaWMNCg0K RnJvbTogQWxleGV5IE1lbG5pa292IDxhYW1lbG5pa292QGZhc3RtYWlsLmZtPg0KRGF0ZTogV2Vk bmVzZGF5LCA1IEZlYnJ1YXJ5IDIwMjAgYXQgMTE6MzkNClRvOiBKZWZmcmV5IFlhc3NraW4gPGp5 YXNza2luQGNocm9taXVtLm9yZz4NCkNjOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5jb20+ LCBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4sICJ3cGFja0BpZXRmLm9yZyIgPHdwYWNrQGlldGYu b3JnPiwgIndwYWNrLWNoYWlyc0BpZXRmLm9yZyIgPHdwYWNrLWNoYWlyc0BpZXRmLm9yZz4sIE1h cnRpbiBUaG9tc29uIDxtdEBtb3ppbGxhLmNvbT4NClN1YmplY3Q6IFJlOiBbV3BhY2tdIMOJcmlj IFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBjaGFydGVyLWlldGYtd3BhY2stMDAtMDQ6ICh3aXRo IENPTU1FTlQpDQoNCk9uIFR1ZSwgRmViIDQsIDIwMjAsIGF0IDY6MzQgUE0sIEplZmZyZXkgWWFz c2tpbiB3cm90ZToNCk9uIFR1ZSwgRmViIDQsIDIwMjAgYXQgNToyNCBBTSBBbGV4ZXkgTWVsbmlr b3YgPGFhbWVsbmlrb3ZAZmFzdG1haWwuZm08bWFpbHRvOmFhbWVsbmlrb3ZAZmFzdG1haWwuZm0+ PiB3cm90ZToNCk9uIFN1biwgRmViIDIsIDIwMjAsIGF0IDM6NTQgUE0sIMOJcmljIFZ5bmNrZSB2 aWEgRGF0YXRyYWNrZXIgd3JvdGU6DQo+IFVuc3VyZSB3aGV0aGVyICJDb25zdHJhaW50cyBvbiBo b3cgY2xpZW50cyBsb2FkIHRoZSBmb3JtYXRzIiBjYW4gYmUgcGFyc2VkIGFzIGENCj4gZ29hbC4N Cg0KR29vZCBwb2ludC4gSSBuZWVkIHRvIGNoZWNrIEplZmZyZXkgd2hhdCB3YXMgaW50ZW5kZWQg aGVyZS4NCg0KVGhpcyBjb21lcyBmcm9tIGEgZGlzY3Vzc2lvbiBhdCB0aGUgQm9GIG92ZXIgbXkg aW5pdGlhbCBub24tZ29hbCBvZiAiRGVmaW5pbmcgdGhlIGRldGFpbHMgb2YgaG93IHdlYiBicm93 c2VycyBsb2FkIHRoZSBmb3JtYXRzIGFuZCBpbnRlcmFjdCB3aXRoIGFueSBwcm90b2NvbHMgd2Ug ZGVmaW5lIGhlcmUuIiBUaGUgbWludXRlcyByZWNvcmQ6DQrCtyAgICAgICAgIE1UOiBvbmUgdGhp bmcgbWlzc2luZyBpcyBvbmUgY2xlYXIgYXJ0aWNpbGF0aW9uIG9mIGhlIGNvbnN0cmFpbnRzIHBl b3BsZSBydW5uaW5nIHRoaXMgc2hvdWxkIG9wZXJhdGUgaW4gb3JkZXIgdG8gbWFpbnRhaW4gZ3Vh cmF0bmVlcy4gYWdyZWUgd2l0aCBka2cuIHdlIGFyZSBzZXR0aW5nIGEgbmV3IGJhciB0aGF0IHJl cXVpcmUgbWVldGluZyBhIGJyYW5kIG5ldyBzZXQgb2YgcmVxdWlyZW1lbnRzLiB0aGF0IHJlbGF0 ZXMgdG8gdGhpbmdzIHRoYXQgbW5vdCwgamVmZnJleSBoYXZlbSBtZW50aW9uZWQuIGFsb25nIHdp dGggcGVyc29uYWxpc2F0aW9uLiB3ZSBzaG91bGQgY2FwdHVyZSB0aGVzZSBhbmQgZG8gYW4gYW5h eWxzaXMgdG8gZW5zdXJlIHRoYXQgd2UgY2FuIGdldCB0aGlzIHJpZ2h0LiAuLi4NCsK3ICAgICAg ICAgYmVuIHNjaHdhcno6IGkgYWdyZWUgd2l0aCBNVC4gJ291dCBvZiBzY29wZSBmb3IgaG93IGJy b3dzZXJzIGxvYWQgZm9ybWF0JyAtLSBubywgd2Ugc2hvdWxkIGxpc3QgY29uc3RyYWludHMuIHRo aXMgY291bGQgYWN0dWFsbHkgYmUgYSB2aWN0b3J5IGZvciBwcml2YWN5IG92ZXIgSFRUUHMgZS5n LiBpZiBzZXJ2ZXJzIHB1c2ggYnVuZGxlcyB0aGlzIG1heSBoYXZlIGJldHRlciBwcml2YWN5IHBy b3BlcnRpZXMuDQpJIHRoaW5rIE1hcnRpbiB3YXMgc3VnZ2VzdGluZyB0aGF0IHRoZSBJRVRGLXNp ZGUgc3BlY2lmaWNhdGlvbnMgc2hvdWxkIGluY2x1ZGUgcmVxdWlyZW1lbnRzIG9uIHRoZSBjbGll bnQgdGhhdCBlbnN1cmUgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgd2Ugd2FudCwgZXZlbiB0aG91 Z2ggd2Ugd291bGRuJ3QgaW5jbHVkZSBkZXRhaWxlZCBhbGdvcml0aG1zIGZvciBob3cgYSB3ZWIg YnJvd3NlciBidWlsZHMgYSBEb2N1bWVudCBvYmplY3Qgb3V0IG9mIHRoZSBmb3JtYXRzLiBJIGRv bid0IGhhdmUgc3Ryb25nIG9waW5pb25zIG9uIGhvdyB0byB3b3JkIHRoYXQgZ29hbC4NCg0KT2su IEkgY2hhbmdlZCB0aGUgc2VudGVuY2UgdG8gcmVhZDoNCg0KIlNwZWNpZnlpbmcgY29uc3RyYWlu dHMgb24gaG93IGNsaWVudHMgbG9hZCB0aGUgZm9ybWF0cyB3aXRob3V0IGRlc2NyaWJpbmcgc3Bl Y2lmaWMgbG9hZGluZyBhbGdvcml0aG0gdG8gaGVscCBhY2hpZXZlIHRoZSBhYm92ZSBnb2Fscy4i DQoNCklmIHlvdSB0aGluayB0aGF0IGZ1cnRoZXIgY2hhbmdlcyBhcmUgbmVlZGVkLCBwbGVhc2Ug bGV0IG1lIGtub3cuDQoNCkJlc3QgUmVnYXJkcywNCkFsZXhleQ0KDQo= --_000_DEB006C9B742452FAD7163C82D98AA24ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjE4NzcxNTYxMzA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0xMzU2NDA0MjMwO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDox NDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1CRSIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gY2xhc3M9IkVtYWlsU3R5bGUxOSI+77u/VDwvc3Bhbj48c3BhbiBjbGFzcz0i RW1haWxTdHlsZTE5Ij48c3BhbiBsYW5nPSJFTi1VUyI+aGFuayB5b3UgQWxleGV5LCB0aGlzIGlz IGV4YWN0bHkgd2hhdCBJIHdhcyBsb29raW5nIGZvcjogdGhpcyBzZW50ZW5jZSBub3cgcGFyc2Vz IGFzIGEgZ29hbA0KPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iRW1haWxTdHlsZTE5Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FwcGxlIENvbG9yIEVtb2pp JnF1b3Q7Ij4mIzEyODUyMTs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJFbWFpbFN0eWxlMTki PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IkVtYWlsU3R5bGUxOSI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBjbGFzcz0iRW1haWxTdHlsZTE5Ij48c3BhbiBsYW5nPSJFTi1VUyI+LcOpcmlj PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToN Cjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkFs ZXhleSBNZWxuaWtvdiAmbHQ7YWFtZWxuaWtvdkBmYXN0bWFpbC5mbSZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+V2VkbmVzZGF5LCA1IEZlYnJ1YXJ5IDIwMjAgYXQgMTE6Mzk8YnI+DQo8Yj5UbzogPC9i PkplZmZyZXkgWWFzc2tpbiAmbHQ7anlhc3NraW5AY2hyb21pdW0ub3JnJmd0Ozxicj4NCjxiPkNj OiA8L2I+RXJpYyBWeW5ja2UgJmx0O2V2eW5ja2VAY2lzY28uY29tJmd0OywgVGhlIElFU0cgJmx0 O2llc2dAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDt3cGFja0BpZXRmLm9yZyZxdW90OyAmbHQ7d3BhY2tA aWV0Zi5vcmcmZ3Q7LCAmcXVvdDt3cGFjay1jaGFpcnNAaWV0Zi5vcmcmcXVvdDsgJmx0O3dwYWNr LWNoYWlyc0BpZXRmLm9yZyZndDssIE1hcnRpbiBUaG9tc29uICZsdDttdEBtb3ppbGxhLmNvbSZn dDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtXcGFja10gw4lyaWMgVnluY2tlJ3MgTm8gT2Jq ZWN0aW9uIG9uIGNoYXJ0ZXItaWV0Zi13cGFjay0wMC0wNDogKHdpdGggQ09NTUVOVCk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIFR1 ZSwgRmViIDQsIDIwMjAsIGF0IDY6MzQgUE0sIEplZmZyZXkgWWFzc2tpbiB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCIgaWQ9InF0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gVHVlLCBGZWIgNCwgMjAyMCBhdCA1 OjI0IEFNIEFsZXhleSBNZWxuaWtvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFhbWVsbmlrb3ZAZmFz dG1haWwuZm0iPmFhbWVsbmlrb3ZAZmFzdG1haWwuZm08L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gU3VuLCBGZWIgMiwgMjAyMCwgYXQg Mzo1NCBQTSwgw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZndDsgVW5zdXJlIHdoZXRoZXIgJnF1b3Q7Q29uc3RyYWludHMgb24gaG93IGNs aWVudHMgbG9hZCB0aGUgZm9ybWF0cyZxdW90OyBjYW4gYmUgcGFyc2VkIGFzIGE8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPiZndDsgZ29hbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+R29vZCBwb2ludC4gSSBuZWVkIHRvIGNoZWNrIEplZmZyZXkgd2hh dCB3YXMgaW50ZW5kZWQgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhpcyBjb21lcyBmcm9tIGEgZGlzY3Vzc2lv biBhdCB0aGUgQm9GIG92ZXIgbXkgaW5pdGlhbCBub24tZ29hbCBvZiAmcXVvdDtEZWZpbmluZyB0 aGUgZGV0YWlscyBvZiBob3cgd2ViIGJyb3dzZXJzIGxvYWQgdGhlIGZvcm1hdHMgYW5kIGludGVy YWN0IHdpdGggYW55IHByb3RvY29scyB3ZSBkZWZpbmUgaGVyZS4mcXVvdDsgVGhlIG1pbnV0ZXMg cmVjb3JkOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPk1UOiBvbmUgdGhpbmcgbWlzc2luZyBpcyBvbmUgY2xlYXIg YXJ0aWNpbGF0aW9uIG9mIGhlIGNvbnN0cmFpbnRzIHBlb3BsZSBydW5uaW5nIHRoaXMgc2hvdWxk IG9wZXJhdGUgaW4gb3JkZXIgdG8gbWFpbnRhaW4gZ3VhcmF0bmVlcy4gYWdyZWUgd2l0aCBka2cu IHdlIGFyZSBzZXR0aW5nIGEgbmV3IGJhciB0aGF0IHJlcXVpcmUgbWVldGluZyBhIGJyYW5kIG5l dyBzZXQgb2YgcmVxdWlyZW1lbnRzLg0KIHRoYXQgcmVsYXRlcyB0byB0aGluZ3MgdGhhdCBtbm90 LCBqZWZmcmV5IGhhdmVtIG1lbnRpb25lZC4gYWxvbmcgd2l0aCBwZXJzb25hbGlzYXRpb24uIHdl IHNob3VsZCBjYXB0dXJlIHRoZXNlIGFuZCBkbyBhbiBhbmF5bHNpcyB0byBlbnN1cmUgdGhhdCB3 ZSBjYW4gZ2V0IHRoaXMgcmlnaHQuIC4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPmJlbiBzY2h3YXJ6OiBpIGFncmVlIHdpdGggTVQuICdv dXQgb2Ygc2NvcGUgZm9yIGhvdyBicm93c2VycyBsb2FkIGZvcm1hdCcgLS0gbm8sIHdlIHNob3Vs ZCBsaXN0IGNvbnN0cmFpbnRzLiB0aGlzIGNvdWxkIGFjdHVhbGx5IGJlIGEgdmljdG9yeSBmb3Ig cHJpdmFjeSBvdmVyIEhUVFBzIGUuZy4gaWYgc2VydmVycyBwdXNoIGJ1bmRsZXMgdGhpcyBtYXkg aGF2ZSBiZXR0ZXIgcHJpdmFjeSBwcm9wZXJ0aWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSB0 aGluayBNYXJ0aW4gd2FzIHN1Z2dlc3RpbmcgdGhhdCB0aGUgSUVURi1zaWRlIHNwZWNpZmljYXRp b25zIHNob3VsZCBpbmNsdWRlIHJlcXVpcmVtZW50cyBvbiB0aGUgY2xpZW50IHRoYXQgZW5zdXJl IHRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIHdlIHdhbnQsIGV2ZW4gdGhvdWdoIHdlIHdvdWxkbid0 IGluY2x1ZGUgZGV0YWlsZWQgYWxnb3JpdGhtcyBmb3IgaG93DQogYSB3ZWIgYnJvd3NlciBidWls ZHMgYSBEb2N1bWVudCBvYmplY3Qgb3V0IG9mIHRoZSBmb3JtYXRzLiBJIGRvbid0IGhhdmUgc3Ry b25nIG9waW5pb25zIG9uIGhvdyB0byB3b3JkIHRoYXQgZ29hbC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPk9rLiBJIGNoYW5nZWQgdGhlIHNlbnRlbmNlIHRvIHJlYWQ6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZxdW90O1NwZWNpZnlpbmcgY29u c3RyYWludHMgb24gaG93IGNsaWVudHMgbG9hZCB0aGUgZm9ybWF0cyB3aXRob3V0IGRlc2NyaWJp bmcgc3BlY2lmaWMgbG9hZGluZyBhbGdvcml0aG0gdG8gaGVscCBhY2hpZXZlIHRoZSBhYm92ZSBn b2Fscy4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+SWYgeW91IHRoaW5rIHRoYXQgZnVydGhlciBjaGFuZ2VzIGFyZSBuZWVkZWQsIHBsZWFz ZSBsZXQgbWUga25vdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QWxleGV5PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_DEB006C9B742452FAD7163C82D98AA24ciscocom_-- From nobody Wed Feb 5 06:51:59 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311BE1200C1; Wed, 5 Feb 2020 06:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_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=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 0lObNKiLL8G5; Wed, 5 Feb 2020 06:51:49 -0800 (PST) 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 3B40C120059; Wed, 5 Feb 2020 06:51:49 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 015Epjfp013013; Wed, 5 Feb 2020 14:51:45 GMT 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=FeSzGWqnk50f6Cg33OpXdUHWQfLO9ccwgQSAU/8fWqU=; b=EdACpLdnqcsxH516KDki9C4DcpnfVSOp2KoAtwUxFBZ4XwNRsi9T0st0rQuL7qjeehsu EHkc6Nb1Lw/P+5LLpfyOfIadNronSWndXG7EnWXU2D7yR0f6NjSIRcRMvgZOauUquf34 el8ywZvSltOiblvod/vmwdIRxaDk3qid3yeXaVh1eeI2Ny/BJUglJ0wmZhiSO+HO9GyF vCzZZ9XYkaGB0Yter6PxsOaKSLvGZTENZr2ldhtB0LHe3ppGs9qJoj979+co8AI7YiMs pV+h+mwJVGgod/HKKgLn+n3VEJd4v5PTT3JZtctlli5Iop4ZkTeNp2FBi088wmpJNjD4 eA== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2xyhn5k6s0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Feb 2020 14:51:45 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 015ElWso000715; Wed, 5 Feb 2020 09:51:40 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint6.akamai.com with ESMTP id 2xykftreqg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 05 Feb 2020 09:51:40 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 5 Feb 2020 09:51:39 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 5 Feb 2020 09:51:39 -0500 From: "Salz, Rich" To: Mark Nottingham , Magnus Westerlund CC: "wpack@ietf.org" , "wpack-chairs@ietf.org" , The IESG Thread-Topic: [Wpack] Magnus Westerlund's No Objection on charter-ietf-wpack-00-04: (with COMMENT) Thread-Index: AQHV22BHJ5I8zqF9yUe/vaYBpZa4nqgMp1kAgAAJcYA= Date: Wed, 5 Feb 2020 14:51:39 +0000 Message-ID: <71FC3167-21D5-4000-8BDE-2B3F94E6EDF5@akamai.com> References: <158082339622.15820.6318276487462018950.idtracker@ietfa.amsl.com> <0D1A45E0-6C1E-47E4-B7D2-C09AE5D8060B@mnot.net> In-Reply-To: <0D1A45E0-6C1E-47E4-B7D2-C09AE5D8060B@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200203 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.125] 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=2020-02-05_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=553 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002050117 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-05_04:2020-02-04, 2020-02-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 suspectscore=0 mlxlogscore=540 malwarescore=0 clxscore=1011 mlxscore=0 lowpriorityscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002050117 Archived-At: Subject: Re: [Wpack] Magnus Westerlund's No Objection on charter-ietf-wpack-00-04: (with COMMENT) 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, 05 Feb 2020 14:51:52 -0000 ICAgID4gUmVsYXRpb25zaGlwIHRvIE90aGVyIFdHcyBhbmQgU0RPcw0KICAgID4gDQogICAgPiBX UEFDSyB3aWxsIHdvcmsgd2l0aCB0aGUgVzNDIGFuZCBXSEFUV0cgdG8gaWRlbnRpZnkgdGhlIGV4 aXN0aW5nIHNlY3VyaXR5IGFuZA0KICAgID4gcHJpdmFjeSBtb2RlbHMgZm9yIHRoZSB3ZWIsIGFu ZCB0byBlbnN1cmUgdGhvc2UgU0RPcyBjYW4gZGVmaW5lIGhvdyB0aGlzIGZvcm1hdA0KICAgID4g aXMgdXNlZCBieSB3ZWIgYnJvd3NlcnMuDQogICAgPiANCiAgICA+IFdpbGwgY2FsbGluZyBXSEFU V0cgYW4gU0RPIGNyZWF0ZSBhbnkgaXNzdWVzIGZvciB0aGUgSUVURj8gV2hhdFdHIGlzIHRvIG15 DQogICAgPiBrbm93bGVkZ2UgYW4gSW5kdXN0cnkgRm9ydW0uDQoNCk9yIGp1c3QgZG8gcy9TRE8v b3JnYW5pemF0aW9ucy8gYW5kIGF2b2lkIHRoZSBwcm9ibGVtIGNvbXBsZXRlbHkuDQoNCg0K From nobody Wed Feb 5 06:53:28 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D791200B3; Wed, 5 Feb 2020 06:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=fastmail.fm header.b=BUviWIhh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NXbNeC4Y 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 JBgGAWLOT-Vy; Wed, 5 Feb 2020 06:53:22 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18712120059; Wed, 5 Feb 2020 06:53:22 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 72E1721BA9; Wed, 5 Feb 2020 09:53:21 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Wed, 05 Feb 2020 09:53:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=iD51A/OZmqrKBHBJIeo7wn7GSwOi4tM MX11UCKgbdK8=; b=BUviWIhhBvajGneJYwMMkVJKMjuG0rpU2eUn9wFVTwxUGnu ZUA1UOrRmgg7P6xDPpD2awUqCde58x3YJK3ZJjKZtBJqaLLjc11oFps1J9zre6kY rsrgHncCcFxLXbFi8zMD79LyG8MJaS6lqBldCqMUC5/tagObLPRSe/WvVmFv7l/K PG2yiB4ok/vR9LMYv6idnP1nYc0LAKbhgtesATgLJKpy8LPOBJsnRnQsz2QmLbal L1HqH1eYEy18ScoXXicXx7vUwCodC+Hye8MtsVLx2/CNJpuovxVzy6SpatFNVYhg qAXtXKPXGbh2RiFFrDlDKSxUdIC9ce1/we7eQ1Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=iD51A/ OZmqrKBHBJIeo7wn7GSwOi4tMMX11UCKgbdK8=; b=NXbNeC4Yc5fupE25Kc9Mdc xK2yHC31JbDbYBBbGtc7XMpx84keAmwvbOa6wh/IFjIGySIa1BBOf3VJu0kK4AEP Fi+sSLecyIe9mQ8+PDz+gQ6IODwrgEPsRe7H9behaxXs2NmzZCU9zQJllA8TFNvk 9NFGEp1+WsdT7QmwySjNJuRm9fljOVjOEee0aCQcrOz93lT8j+PYnPBe44EuEXS1 ELXumJQczlwMPUsTDzymI0YsVy7aml33qICqt5a7BexWijkwIRqOYSxeHPJQVn9t no0zhX618Oed+qgUZb+EHXFmUILhwqhbe4uY+mRFfs+FfkZj6ZOkYqQ4uXetLYnA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrhedugdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr rghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2546B660065; Wed, 5 Feb 2020 09:53:21 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <2f6ed576-27fd-4fa5-86ee-faf40102462a@www.fastmail.com> In-Reply-To: <158087731973.15693.2828361095219090722.idtracker@ietfa.amsl.com> References: <158087731973.15693.2828361095219090722.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2020 14:52:43 +0000 From: "Alexey Melnikov" To: "Barry Leiba" , "The IESG" Cc: wpack@ietf.org, wpack-chairs@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] =?utf-8?q?Barry_Leiba=27s_No_Objection_on_charter-ietf-w?= =?utf-8?q?pack-00-05=3A_=28with_COMMENT=29?= 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, 05 Feb 2020 14:53:23 -0000 Hi Barry, On Wed, Feb 5, 2020, at 4:35 AM, Barry Leiba via Datatracker wrote: > Barry Leiba has entered the following ballot position for > charter-ietf-wpack-00-05: No Objection > In particular, because > something is in the initial document set (consisting of > does not imply > > I suggest that the complaint about this part could be best addressed by not > listing the drafts in the charter and by saying it this way: > > NEW > In particular, because > something is in an initial working group draft does not imply > END I used your text, thank you. Best Regards, Alexey From nobody Wed Feb 5 07:01:36 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D4E1200C1; Wed, 5 Feb 2020 07:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=fastmail.fm header.b=wNke/kLc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D6T8LbF+ 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 4zjgv60WxRmS; Wed, 5 Feb 2020 07:01:20 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364481200BA; Wed, 5 Feb 2020 07:01:20 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3B8EC200D7; Wed, 5 Feb 2020 10:01:19 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Wed, 05 Feb 2020 10:01:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=izCfB1n/vGgtGEu5PzFoDHrIpgsNQDG Lewp5na/TgFc=; b=wNke/kLc/ytZuju/a1Wj7s3A1Pa9BESAgFlvZ7s7syIsnf3 Pf2c96UPfg+iYVBm9ArtpO7LElkA/UVQOPPLaCwP8liFOtAXNg7Xugk8QeSxgJ8b +Fsde1d7Xjw3KxbXFnhn19CQnWBX1SDIZlQAPArYhsMehWtRbS3Hf8qCNEW+zhkq ely5qz8Hemimin0sVzlGcdGiDGVqnrqftdPiBAV1UA9OPJdL1CnAAGY5ydnkgT1N kvp4pn2ibi8D6tDt4+R/TecRLXg5x6EDAsDOrqS0qk+fwXik0MjwaktssZ0Ff84F xnwe+AxGejr9z456np9HMpQctQiGEVGqd6uppTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=izCfB1 n/vGgtGEu5PzFoDHrIpgsNQDGLewp5na/TgFc=; b=D6T8LbF+X4QEgPRDMPKv1Y 5FIxsKjXvVpfoHGmmnvk1fEAGo62F9+al26q+Li/e0pwYU5H/DePweX5nD5q3Zq/ dwG837GHEZ1LxM/NWEawo7TN9J6c7DweJ9CIZPya5+hfxiQTzAe117PzyIjIqzBQ HJYV0Ge1zxLg+i4J5RJGq8crKrBe0lOkzggwyGijC9lgQyfGAucZjl/NCJLXskYX hMBYp1KhHnYY0rEQQqFCvbzbYYuu4A9y9BrgYdqCLlj76N7BQeAumgFDStUEz42p x7CuIllYHe5D+cEHgJCNhlsao5Vm0RXiUe023SGyktsSY5FEoedcMbnzQU2AYVLA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrhedugdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C0AF2660069; Wed, 5 Feb 2020 10:01:18 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <6330ccdb-6e78-4f96-b256-9b4421f66413@www.fastmail.com> In-Reply-To: References: <158082339622.15820.6318276487462018950.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2020 15:00:32 +0000 From: "Alexey Melnikov" To: "Jeffrey Yasskin" , "Magnus Westerlund" Cc: wpack@ietf.org, wpack-chairs@ietf.org, "The IESG" Content-Type: multipart/alternative; boundary=7b7ccc8e114340268e1945f7db985b50 Archived-At: Subject: Re: [Wpack] =?utf-8?q?Magnus_Westerlund=27s_No_Objection_on_charter-?= =?utf-8?q?ietf-wpack-00-04=3A_=28with_COMMENT=29?= 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, 05 Feb 2020 15:01:23 -0000 --7b7ccc8e114340268e1945f7db985b50 Content-Type: text/plain On Tue, Feb 4, 2020, at 9:25 PM, Jeffrey Yasskin wrote: > On Tue, Feb 4, 2020 at 5:36 AM Magnus Westerlund via Datatracker wrote: >> Magnus Westerlund has entered the following ballot position for >> charter-ietf-wpack-00-04: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-wpack/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I have some questions. >> >> Does there exist an easy way to resolve the clash between this primary and >> non-goal? Primary goal: * The ability to create an unsigned snapshot of a web >> page without the cooperation of its publisher. >> >> Non-goal: >> * A way to distribute the private portions of a website. For example, WPACK >> might define a way to distribute a messaging application but wouldn't >> define a way to distribute individual messages without a direct connection to >> the messaging application's origin server. >> >> So the issue I wonder over, is that if I as a user decide to snapshot a >> web-page that contains some server-side dynamically generated resources. To my >> understanding that would result in that dynamically user specific generated >> content would be captured. How does this relate to the above non-goal. Or are >> these two different usages of the targeted solution. One to allow snap shoting >> what one actually provided, and another a configuration for distributing a part >> of a web-site? >> >> The above thought lead to the question: Is it at all possible to prevent a user >> from sharing their private content if using this mechanism? Will the packager >> be able to determine what is private and what is not so that the user can >> select between a snapshot and sharing the general part of a web-site? > > These are talking about the difference between 1) unsigned content, 2) signed content, and 3) signed and encrypted content, where I wanted to say that (3) is out of scope. It's safe to share unsigned personalized content with the permission of whoever's data it is. It's not safe for the recipient to use signed personalized content even with the permission of the owner of the data. So, the wording of "A way to distribute the private portions of a website." is missing an indication that it's about distribution when signed as the website or in a way that the client will trust that it's authentically from the website. > > I don't know a way for the client to automatically identify what's private or not without cooperation from the website. If the website does provide a package, I think it'd make sense for clients to give their users the ability to save either the website's package or an unsigned snapshot of what they're currently looking at. Magnus, does the above address your question? Is any change to the text needed? If yes, can you or Jeffrey suggest updated text? Best Regards, Alexey --7b7ccc8e114340268e1945f7db985b50 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, = 2020, at 9:25 PM, Jeffrey Yasskin wrote:
On Tue, Feb 4, 2020 at 5= :36 AM Magnus Westerlund via Datatracker <noreply@ietf.org> wrote:
Magnus Westerlund has entered the following ballot position= for
charter-ietf-wpack-00-04: No Objection

When responding, please keep the subject line intact a= nd reply to all
email addresses included in the To and CC= lines. (Feel free to cut this
introductory paragraph, ho= wever.)



T= he document, along with other ballot positions, can be found here:



--= --------------------------------------------------------------------
=
COMMENT:
------------------------------------= ----------------------------------

I have= some questions.

Does there exist an easy= way to resolve the clash between this primary and
non-go= al? Primary goal: * The ability to create an unsigned snapshot of a web<= br>
page without the cooperation of its publisher.
<= div>
Non-goal:
* A way to distribute the = private portions of a website. For example, WPACK
might d= efine a way to distribute a messaging application but wouldn't
=
define a way to distribute individual messages without a direct co= nnection to
the messaging application's origin server.

So the issue I wonder over, is that if I as= a user decide to snapshot a
web-page that contains some = server-side dynamically generated resources. To my
unders= tanding that would result in that dynamically user specific generated
content would be captured. How does this relate to the abov= e non-goal. Or are
these two different usages of the targ= eted solution. One to allow snap shoting
what one actuall= y provided, and another a configuration for distributing a part
of a web-site?

The above thought l= ead to the question: Is it at all possible to prevent a user
from sharing their private content if using this mechanism? Will the= packager
be able to determine what is private and what i= s not so that the user can
select between a snapshot and = sharing the general part of a web-site?

<= /div>
These are talking about the difference between 1) unsigned con= tent, 2) signed content, and 3) signed and encrypted content, where I wa= nted to say that (3) is out of scope. It's safe to share unsigned person= alized content with the permission of whoever's data it is. It's not saf= e for the recipient to use signed personalized content even with the per= mission of the owner of the data. So, the wording of "A way to distribut= e the private portions of a website." is missing an indication that it's= about distribution when signed as the website or in a way that the clie= nt will trust that it's authentically from the website.
I don't know a way for the client to automatically identify= what's private or not without cooperation from the website. If the webs= ite does provide a package, I think it'd make sense for clients to give = their users the ability to save either the website's package or an unsig= ned snapshot of what they're currently looking at.
=

Magnus, does the above address your que= stion? Is any change to the text needed? If yes, can you or Jeffrey sugg= est updated text?

Best Regards,
Alexey --7b7ccc8e114340268e1945f7db985b50-- From nobody Wed Feb 5 09:06:29 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E1A120145; Wed, 5 Feb 2020 09:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=cooperw.in header.b=CsMVP+zh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=07WN8Q+O 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 IQO0I6WCI4On; Wed, 5 Feb 2020 09:06:21 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38201200BA; Wed, 5 Feb 2020 09:06:20 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C84DE21EE9; Wed, 5 Feb 2020 12:06:19 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 05 Feb 2020 12:06:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=pOVLnsWG3gSVZfBvmPA144h qDId/7G2XdNqIqsQ/OQI=; b=CsMVP+zhpfY9BbbiazYL5cfwYXP0x6ED3kIsAG4 AEY/C3hIhCiLXIiFFf0hM4jDw56x9zgEJ2fA5x7xfTv/5HNp1Njt2G/qCXDdZWFF Sq0kEVottm+f9YjaUhAf5YZBhhR7hMeTCTl2P/iG1CikSMtAchQSHfkAxDnVQ/oP sRDs1jO7LynthVHzSzITNGmSVPZRWhMss4fFdFtWqdal+sTc5DPH3twrXKm3QClF cg/v/2qZ/zM5I+SapdNic2PTN7lJ+giFdLK1jZLa96b6h7iHaDU2p4NOR4yFTgKh AMHv2lPrlGwiRvUNuqKRKyS2VgX/xjiAoJ1hLNqh6PUD81A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=pOVLns WG3gSVZfBvmPA144hqDId/7G2XdNqIqsQ/OQI=; b=07WN8Q+OjiB+pUYVdmEmF5 9hgakFdkl3tginvgJWSEDtnK9+MSU7ELKZLt4l2hrNBoOD4/2o0Bibz8+UFHaYad SJPfJIw2pL9QuJNAQc6+81sHqZgBBNCaevUriPuqKdRnaFaRV+km/xQMIdyGORUd NzjGezenoRPdqp7FZTqXMGZOgBDay5tpBQW0/HynPnjb7cttidkbA1hZDQdZXMKW AhWj/PlpU749T/ubaH2zRg1nV/jQS7qI0R8q4arGqFUAubSvCNnSpZVJEa4ESTwb WU1vWjMs1fUqntzbW9HaETpsZ1e/s91Hc8GDI9i7FLTA76f1Vn8+iA474fYbZj9w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrhedugdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtvdenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrghinh epihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrkedvnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhoph gvrhifrdhinh X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id 01DDA3060A08; Wed, 5 Feb 2020 12:06:18 -0500 (EST) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_043A05CC-D5FF-4FA5-A889-88BDC67C8D34" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 5 Feb 2020 12:06:18 -0500 In-Reply-To: <6330ccdb-6e78-4f96-b256-9b4421f66413@www.fastmail.com> Cc: Jeffrey Yasskin , Magnus Westerlund , wpack@ietf.org, wpack-chairs@ietf.org, IESG To: Alexey Melnikov References: <158082339622.15820.6318276487462018950.idtracker@ietfa.amsl.com> <6330ccdb-6e78-4f96-b256-9b4421f66413@www.fastmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Wpack] Magnus Westerlund's No Objection on charter-ietf-wpack-00-04: (with COMMENT) 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, 05 Feb 2020 17:06:24 -0000 --Apple-Mail=_043A05CC-D5FF-4FA5-A889-88BDC67C8D34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 5, 2020, at 10:00 AM, Alexey Melnikov = wrote: >=20 > On Tue, Feb 4, 2020, at 9:25 PM, Jeffrey Yasskin wrote: >> On Tue, Feb 4, 2020 at 5:36 AM Magnus Westerlund via Datatracker = > wrote: >> Magnus Westerlund has entered the following ballot position for >> charter-ietf-wpack-00-04: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-wpack/ = >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I have some questions. >>=20 >> Does there exist an easy way to resolve the clash between this = primary and >> non-goal? Primary goal: * The ability to create an unsigned snapshot = of a web >> page without the cooperation of its publisher. >>=20 >> Non-goal: >> * A way to distribute the private portions of a website. For example, = WPACK >> might define a way to distribute a messaging application but wouldn't >> define a way to distribute individual messages without a direct = connection to >> the messaging application's origin server. >>=20 >> So the issue I wonder over, is that if I as a user decide to snapshot = a >> web-page that contains some server-side dynamically generated = resources. To my >> understanding that would result in that dynamically user specific = generated >> content would be captured. How does this relate to the above = non-goal. Or are >> these two different usages of the targeted solution. One to allow = snap shoting >> what one actually provided, and another a configuration for = distributing a part >> of a web-site? >>=20 >> The above thought lead to the question: Is it at all possible to = prevent a user >> from sharing their private content if using this mechanism? Will the = packager >> be able to determine what is private and what is not so that the user = can >> select between a snapshot and sharing the general part of a web-site? >>=20 >> These are talking about the difference between 1) unsigned content, = 2) signed content, and 3) signed and encrypted content, where I wanted = to say that (3) is out of scope. It's safe to share unsigned = personalized content with the permission of whoever's data it is. It's = not safe for the recipient to use signed personalized content even with = the permission of the owner of the data. So, the wording of "A way to = distribute the private portions of a website." is missing an indication = that it's about distribution when signed as the website or in a way that = the client will trust that it's authentically from the website. >>=20 FWIW, I was also confused about this when I read it, so I think it would = help to clarify. Alissa >> I don't know a way for the client to automatically identify what's = private or not without cooperation from the website. If the website does = provide a package, I think it'd make sense for clients to give their = users the ability to save either the website's package or an unsigned = snapshot of what they're currently looking at. >=20 > Magnus, does the above address your question? Is any change to the = text needed? If yes, can you or Jeffrey suggest updated text? >=20 > Best Regards, > Alexey --Apple-Mail=_043A05CC-D5FF-4FA5-A889-88BDC67C8D34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Feb 5, 2020, at 10:00 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

On = Tue, Feb 4, 2020, at 9:25 PM, Jeffrey Yasskin wrote:
On Tue, Feb 4, 2020 = at 5:36 AM Magnus Westerlund via Datatracker <noreply@ietf.org> = wrote:
Magnus = Westerlund has entered the following ballot position for
charter-ietf-wpack-00-04: No = Objection

When responding, please keep the subject line intact and = reply to all
email addresses = included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The = document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-wpack/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

I have some questions.

Does there exist an easy way to resolve = the clash between this primary and
non-goal? Primary goal: * The ability to create an unsigned = snapshot of a web
page without the = cooperation of its publisher.

Non-goal:
* A way to distribute the private portions of a website. For = example, WPACK
might define a way to = distribute a messaging application but wouldn't
define a way to distribute individual messages without a = direct connection to
the messaging = application's origin server.

So the issue I wonder over, is that if = I as a user decide to snapshot a
web-page that contains some server-side dynamically generated = resources. To my
understanding that = would result in that dynamically user specific generated
content would be captured. How does = this relate to the above non-goal. Or are
these two different usages of the targeted solution. One to = allow snap shoting
what one actually = provided, and another a configuration for distributing a part
of a web-site?

The above thought lead = to the question: Is it at all possible to prevent a user
from sharing their private content if = using this mechanism? Will the packager
be able to determine what is private and what is not so that = the user can
select between a = snapshot and sharing the general part of a web-site?

These are talking about the difference between 1) unsigned = content, 2) signed content, and 3) signed and encrypted content, where I = wanted to say that (3) is out of scope. It's safe to share unsigned = personalized content with the permission of whoever's data it is. It's = not safe for the recipient to use signed personalized content even with = the permission of the owner of the data. So, the wording of "A way to = distribute the private portions of a website." is missing an indication = that it's about distribution when signed as the website or in a way that = the client will trust that it's authentically from the website.


FWIW, I was also confused about this when I read = it, so I think it would help to clarify.

Alissa

I don't know a way for the = client to automatically identify what's private or not without = cooperation from the website. If the website does provide a package, I = think it'd make sense for clients to give their users the ability to = save either the website's package or an unsigned snapshot of what = they're currently looking at.

Magnus,= does the above address your question? Is any change to the text needed? = If yes, can you or Jeffrey suggest updated text?

Best Regards,
Alexey

= --Apple-Mail=_043A05CC-D5FF-4FA5-A889-88BDC67C8D34-- From nobody Wed Feb 5 09:31:41 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E095120116; Wed, 5 Feb 2020 09:31:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: wpack-chairs@ietf.org, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158092389711.12848.12402128420849051568.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2020 09:31:37 -0800 Archived-At: Subject: [Wpack] Alissa Cooper's No Objection on charter-ietf-wpack-00-07: (with COMMENT) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 17:31:37 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-wpack-00-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-wpack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "* A low likelihood that the new format increases centralization or power imbalances on the web. See discussion of this in " Unlike the other goals listed, it's hard to see how this is actionable. Will the WG make design decisions differently whether this is in the charter or not? If this working group were designing a system architecture or a protocol with an architecture that implied relationships prone to centralization would need to be created or strengthened for deployment purposes, perhaps this would be an appropriate goal. But the scope here is to specify a format that will be used in the context of the existing web with all of its existing centralization and power imbalances derived from the economic properties of the businesses operating within it. To me, stating this goal is sort of like saying we'll try not to throw kindling on a forest fire that is already propelled by gale force winds. We can say we'll do that, but what actually happens won't be determined by whether we do it or not. From nobody Wed Feb 5 11:44:58 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE03012022C; Wed, 5 Feb 2020 11:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 AaAnBQ30VJpE; Wed, 5 Feb 2020 11:44:50 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140041.outbound.protection.outlook.com [40.107.14.41]) (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 25E9A12022A; Wed, 5 Feb 2020 11:44:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jQaG0q+BAPOt4sTjUfViSoq2xkIDbVofsBBYLfhu5jKrkXXOGCNxAfdWSsVHSC/F0gaP3odyzIDapcytpvq5rCko2WmTlU6N5WdeuTR2TwKmMoPWy3WNNrBoeNVvorErB+8QZjoYM/KkI4KfY64s/MbfDPngRy7UaKyZ/p8llBwGhLLEvEQ94i4OLFz6EHtI4uFumJwX1gCjv5cvtVayz+uTsxNIY8j3D4uA3E9pOeoPrmrRDwRHIulKzCIE/pF8ofwn/WZHeEGLSMs/euauIG9DIEEa2qXoufltnST5bcmlfnR0gIl+t1ok/o1J5cLuBR+Fc/uHaJO7pzQX6CJcDg== 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=1Qa+twFnkyQk6jhvxPB4+wsCvrdfvptCSp3/S9w35M8=; b=KMbBMEa/5IZJgBdAgbgUBYdfhbKYYP0wXpy0QbOgQxUarOBmdtQTr1tUu42MI3mJp6ttHbBOQwn2ZRHO/S6Q6U+ihS7JQbIuYKmTOEKS+TIq/v8lBYh6n9Ar9DZdScfgi5cWFV8E1aI7GmCka0MKCDCKqn+SGW1j+z0+uJyL5dN3zgLJL3xt2XWfNNVLYe+dj/lNs0HME/CHxEEPeNRyZM8dObYy7iZzUVaIQ9GGowsejB9ZQLEEhZ2/g8R3uSru6mFxNuI9UyzRrmONto+fGYs9l3MMs7JB9fAFIginUrPVpMc3fWXXkEB1lAI/bFAn9Q6zZbFgpluW5CUXvXP1TQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1Qa+twFnkyQk6jhvxPB4+wsCvrdfvptCSp3/S9w35M8=; b=HncOVrmJ95H72AMeG9qHK8SzT1OguEWDX+oHt6PhZEQVOCL5l6nr+MNYnynpcChTJI3RUBV172bYdVOX1V566E91onyW8vTaOk5anjnFBAEZIMo6GM6lbRZ3QS8DogX9oU6DwKCDRybBRpOQpGc0FrO4h3B2phbzZVFFROXasZI= Received: from AM6PR07MB4566.eurprd07.prod.outlook.com (20.177.39.83) by AM6PR07MB5415.eurprd07.prod.outlook.com (20.178.91.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.9; Wed, 5 Feb 2020 19:44:47 +0000 Received: from AM6PR07MB4566.eurprd07.prod.outlook.com ([fe80::8403:1777:b46b:2678]) by AM6PR07MB4566.eurprd07.prod.outlook.com ([fe80::8403:1777:b46b:2678%7]) with mapi id 15.20.2707.018; Wed, 5 Feb 2020 19:44:47 +0000 From: Magnus Westerlund To: Alissa Cooper , Alexey Melnikov CC: Jeffrey Yasskin , "wpack@ietf.org" , "wpack-chairs@ietf.org" , IESG Thread-Topic: [Wpack] Magnus Westerlund's No Objection on charter-ietf-wpack-00-04: (with COMMENT) Thread-Index: AQHV22AmsaoHDWYFr0K9gZKHm02YWqgLjGuAgAEm2gCAACMkAIAALEdn Date: Wed, 5 Feb 2020 19:44:47 +0000 Message-ID: References: <158082339622.15820.6318276487462018950.idtracker@ietfa.amsl.com> <6330ccdb-6e78-4f96-b256-9b4421f66413@www.fastmail.com>, In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [90.232.87.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: af4b699e-22f1-4da5-1a12-08d7aa73db3f x-ms-traffictypediagnostic: AM6PR07MB5415: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(346002)(376002)(366004)(199004)(189003)(54906003)(6486002)(81166006)(6512007)(316002)(110136005)(86362001)(71200400001)(2906002)(33656002)(36756003)(478600001)(8676002)(8936002)(81156014)(91956017)(4326008)(66946007)(66446008)(64756008)(76116006)(66476007)(66556008)(44832011)(6506007)(186003)(53546011)(5660300002)(26005)(2616005)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5415; H:AM6PR07MB4566.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ixJgJVULGxEQmhbnB27Zw1jE9H+TJOYgB9dBMDMof2rXWyjcGLxd+cM/rQcyMp4CEZdflYHkEHKVh/bauP1OuiCFwOwaWDaarjCTlCNw5p2vjR66teain1K+PLdmj2WAhi/Piu2RmzpE7UILg9NQeeGL+f1JWO5npiEf6IUzRJl8A6HaRTjXw6g/3WsYxPQwAJRyh73Bews9y3fIPusAKyUGIgECHB8XdNcvKLoXFKOaaVQ/7DBLP7vpT3xqq017YaXUTREMJDHMO2gc/AS+YxI1nPYewH/Ty9FyxZE2T6KOgiQ2NOE5LmmxtvonmHVFVPdjeYn+GAfJOYRw9k6ZgtuqdLjLYPe9d2nbBR1dZdKES2MSuSNc32zeVaKMGWM+WwfbCBbt8m/2PFp+ylA4x5qUJhiSbRTyhBnexbqeSz2jntHxYQNCNgxMBVG1ObVnJsq12NN8QytFH4ghqbiNN0PRtFyFUTjTv1sj9/FbUOMcePeweHx9aauIub+uzpUIlADHzknNxptunaYtGo/pqg== x-ms-exchange-antispam-messagedata: RgD5054X+vPslQcUUFI8ZphAXOnEgqSAvIf/yzqsNXjGzHQ/51RKmTp+NTc4PgxVY/EYucaqzMlOC5V64op+gnKm/5JD8L1mQT9y90JCQv9hDBn8Q9dTF2umhZqSvEGy3G62JR9p+YuZQ4wIfSLHTg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DC7E7D258DDD48AC92685BDC6D60B976ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: af4b699e-22f1-4da5-1a12-08d7aa73db3f X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 19:44:47.1261 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ULptXOfjplkBvR1uBGciX0GFm5aMLOriXxpkBhJw35QjuJE2+sAbnB1DUb8DVsXI9040GrGUF1n9lwgecOYMPjZgEZRhdfYnGehUEmwrYes= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5415 Archived-At: Subject: Re: [Wpack] Magnus Westerlund's No Objection on charter-ietf-wpack-00-04: (with COMMENT) 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, 05 Feb 2020 19:44:54 -0000 --_000_DC7E7D258DDD48AC92685BDC6D60B976ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBJIHRoaW5rIGFkZHJlc3NpbmcgdGhpcyB3b3VsZCBiZSBnb29kLiBJIGFtIG9uIG15IHdh eSB0byBhIHNob3J0IHZhY2F0aW9uIEkgd291bGQgcmVjb21tZW5kIHRoYXQgeW91IHdvcmsgb24g dGhlIHByb3Bvc2FsLiBJZiB5b3Ugd2FudCBmZWVkYmFjayBJIGNhbiBkbyB0aGF0IG9uIE1vbmRh eS4NCg0KQ2hlZXJzDQoNCk1hZ251cw0KDQoNCi0tLQ0KU2tpY2thdCBmcsOlbiBXb3Jrc3BhY2Ug T05FIEJveGVyPGh0dHBzOi8vd2hhdGlzd29ya3NwYWNlb25lLmNvbS9ib3hlcj4NCg0KRGVuIDUg ZmVicnVhcmkgMjAyMCAxODowNjozMCBDRVQgQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3Blcncu aW4+IHNrcmV2Og0KDQoNCk9uIEZlYiA1LCAyMDIwLCBhdCAxMDowMCBBTSwgQWxleGV5IE1lbG5p a292IDxhYW1lbG5pa292QGZhc3RtYWlsLmZtPG1haWx0bzphYW1lbG5pa292QGZhc3RtYWlsLmZt Pj4gd3JvdGU6DQoNCk9uIFR1ZSwgRmViIDQsIDIwMjAsIGF0IDk6MjUgUE0sIEplZmZyZXkgWWFz c2tpbiB3cm90ZToNCk9uIFR1ZSwgRmViIDQsIDIwMjAgYXQgNTozNiBBTSBNYWdudXMgV2VzdGVy bHVuZCB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc8bWFpbHRvOm5vcmVwbHlAaWV0 Zi5vcmc+PiB3cm90ZToNCk1hZ251cyBXZXN0ZXJsdW5kIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KY2hhcnRlci1pZXRmLXdwYWNrLTAwLTA0OiBObyBPYmpl Y3Rpb24NCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGlu dGFjdCBhbmQgcmVwbHkgdG8gYWxsDQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRv IGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KaW50cm9kdWN0b3J5IHBhcmFn cmFwaCwgaG93ZXZlci4pDQoNCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFs bG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9jaGFydGVyLWlldGYtd3BhY2svDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01N RU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpJIGhhdmUgc29tZSBxdWVzdGlvbnMuDQoNCkRvZXMgdGhl cmUgZXhpc3QgYW4gZWFzeSB3YXkgdG8gcmVzb2x2ZSB0aGUgY2xhc2ggYmV0d2VlbiB0aGlzIHBy aW1hcnkgYW5kDQpub24tZ29hbD8gUHJpbWFyeSBnb2FsOiAqIFRoZSBhYmlsaXR5IHRvIGNyZWF0 ZSBhbiB1bnNpZ25lZCBzbmFwc2hvdCBvZiBhIHdlYg0KcGFnZSB3aXRob3V0IHRoZSBjb29wZXJh dGlvbiBvZiBpdHMgcHVibGlzaGVyLg0KDQpOb24tZ29hbDoNCiogQSB3YXkgdG8gZGlzdHJpYnV0 ZSB0aGUgcHJpdmF0ZSBwb3J0aW9ucyBvZiBhIHdlYnNpdGUuIEZvciBleGFtcGxlLCBXUEFDSw0K bWlnaHQgZGVmaW5lIGEgd2F5IHRvIGRpc3RyaWJ1dGUgYSBtZXNzYWdpbmcgYXBwbGljYXRpb24g YnV0IHdvdWxkbid0DQpkZWZpbmUgYSB3YXkgdG8gZGlzdHJpYnV0ZSBpbmRpdmlkdWFsIG1lc3Nh Z2VzIHdpdGhvdXQgYSBkaXJlY3QgY29ubmVjdGlvbiB0bw0KdGhlIG1lc3NhZ2luZyBhcHBsaWNh dGlvbidzIG9yaWdpbiBzZXJ2ZXIuDQoNClNvIHRoZSBpc3N1ZSBJIHdvbmRlciBvdmVyLCBpcyB0 aGF0IGlmIEkgYXMgYSB1c2VyIGRlY2lkZSB0byBzbmFwc2hvdCBhDQp3ZWItcGFnZSB0aGF0IGNv bnRhaW5zIHNvbWUgc2VydmVyLXNpZGUgZHluYW1pY2FsbHkgZ2VuZXJhdGVkIHJlc291cmNlcy4g VG8gbXkNCnVuZGVyc3RhbmRpbmcgdGhhdCB3b3VsZCByZXN1bHQgaW4gdGhhdCBkeW5hbWljYWxs eSB1c2VyIHNwZWNpZmljIGdlbmVyYXRlZA0KY29udGVudCB3b3VsZCBiZSBjYXB0dXJlZC4gSG93 IGRvZXMgdGhpcyByZWxhdGUgdG8gdGhlIGFib3ZlIG5vbi1nb2FsLiBPciBhcmUNCnRoZXNlIHR3 byBkaWZmZXJlbnQgdXNhZ2VzIG9mIHRoZSB0YXJnZXRlZCBzb2x1dGlvbi4gT25lIHRvIGFsbG93 IHNuYXAgc2hvdGluZw0Kd2hhdCBvbmUgYWN0dWFsbHkgcHJvdmlkZWQsIGFuZCBhbm90aGVyIGEg Y29uZmlndXJhdGlvbiBmb3IgZGlzdHJpYnV0aW5nIGEgcGFydA0Kb2YgYSB3ZWItc2l0ZT8NCg0K VGhlIGFib3ZlIHRob3VnaHQgbGVhZCB0byB0aGUgcXVlc3Rpb246IElzIGl0IGF0IGFsbCBwb3Nz aWJsZSB0byBwcmV2ZW50IGEgdXNlcg0KZnJvbSBzaGFyaW5nIHRoZWlyIHByaXZhdGUgY29udGVu dCBpZiB1c2luZyB0aGlzIG1lY2hhbmlzbT8gV2lsbCB0aGUgcGFja2FnZXINCmJlIGFibGUgdG8g ZGV0ZXJtaW5lIHdoYXQgaXMgcHJpdmF0ZSBhbmQgd2hhdCBpcyBub3Qgc28gdGhhdCB0aGUgdXNl ciBjYW4NCnNlbGVjdCBiZXR3ZWVuIGEgc25hcHNob3QgYW5kIHNoYXJpbmcgdGhlIGdlbmVyYWwg cGFydCBvZiBhIHdlYi1zaXRlPw0KDQpUaGVzZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIDEpIHVuc2lnbmVkIGNvbnRlbnQsIDIpIHNpZ25lZCBjb250ZW50LCBhbmQg Mykgc2lnbmVkIGFuZCBlbmNyeXB0ZWQgY29udGVudCwgd2hlcmUgSSB3YW50ZWQgdG8gc2F5IHRo YXQgKDMpIGlzIG91dCBvZiBzY29wZS4gSXQncyBzYWZlIHRvIHNoYXJlIHVuc2lnbmVkIHBlcnNv bmFsaXplZCBjb250ZW50IHdpdGggdGhlIHBlcm1pc3Npb24gb2Ygd2hvZXZlcidzIGRhdGEgaXQg aXMuIEl0J3Mgbm90IHNhZmUgZm9yIHRoZSByZWNpcGllbnQgdG8gdXNlIHNpZ25lZCBwZXJzb25h bGl6ZWQgY29udGVudCBldmVuIHdpdGggdGhlIHBlcm1pc3Npb24gb2YgdGhlIG93bmVyIG9mIHRo ZSBkYXRhLiBTbywgdGhlIHdvcmRpbmcgb2YgIkEgd2F5IHRvIGRpc3RyaWJ1dGUgdGhlIHByaXZh dGUgcG9ydGlvbnMgb2YgYSB3ZWJzaXRlLiIgaXMgbWlzc2luZyBhbiBpbmRpY2F0aW9uIHRoYXQg aXQncyBhYm91dCBkaXN0cmlidXRpb24gd2hlbiBzaWduZWQgYXMgdGhlIHdlYnNpdGUgb3IgaW4g YSB3YXkgdGhhdCB0aGUgY2xpZW50IHdpbGwgdHJ1c3QgdGhhdCBpdCdzIGF1dGhlbnRpY2FsbHkg ZnJvbSB0aGUgd2Vic2l0ZS4NCg0KDQpGV0lXLCBJIHdhcyBhbHNvIGNvbmZ1c2VkIGFib3V0IHRo aXMgd2hlbiBJIHJlYWQgaXQsIHNvIEkgdGhpbmsgaXQgd291bGQgaGVscCB0byBjbGFyaWZ5Lg0K DQpBbGlzc2ENCg0KSSBkb24ndCBrbm93IGEgd2F5IGZvciB0aGUgY2xpZW50IHRvIGF1dG9tYXRp Y2FsbHkgaWRlbnRpZnkgd2hhdCdzIHByaXZhdGUgb3Igbm90IHdpdGhvdXQgY29vcGVyYXRpb24g ZnJvbSB0aGUgd2Vic2l0ZS4gSWYgdGhlIHdlYnNpdGUgZG9lcyBwcm92aWRlIGEgcGFja2FnZSwg SSB0aGluayBpdCdkIG1ha2Ugc2Vuc2UgZm9yIGNsaWVudHMgdG8gZ2l2ZSB0aGVpciB1c2VycyB0 aGUgYWJpbGl0eSB0byBzYXZlIGVpdGhlciB0aGUgd2Vic2l0ZSdzIHBhY2thZ2Ugb3IgYW4gdW5z aWduZWQgc25hcHNob3Qgb2Ygd2hhdCB0aGV5J3JlIGN1cnJlbnRseSBsb29raW5nIGF0Lg0KDQpN YWdudXMsIGRvZXMgdGhlIGFib3ZlIGFkZHJlc3MgeW91ciBxdWVzdGlvbj8gSXMgYW55IGNoYW5n ZSB0byB0aGUgdGV4dCBuZWVkZWQ/IElmIHllcywgY2FuIHlvdSBvciBKZWZmcmV5IHN1Z2dlc3Qg dXBkYXRlZCB0ZXh0Pw0KDQpCZXN0IFJlZ2FyZHMsDQpBbGV4ZXkNCg0K --_000_DC7E7D258DDD48AC92685BDC6D60B976ericssoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9Imx0 ciI+WWVzLCBJIHRoaW5rIGFkZHJlc3NpbmcgdGhpcyB3b3VsZCBiZSBnb29kLiBJIGFtIG9uIG15 IHdheSB0byBhIHNob3J0IHZhY2F0aW9uIEkgd291bGQgcmVjb21tZW5kIHRoYXQgeW91IHdvcmsg b24gdGhlIHByb3Bvc2FsLiBJZiB5b3Ugd2FudCBmZWVkYmFjayBJIGNhbiBkbyB0aGF0IG9uIE1v bmRheS4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNoZWVyczwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+TWFnbnVzPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJkcmFmdC1icmVhayI+ PC9zcGFuPjxicj4NCjxicj4NCi0tLTxicj4NClNraWNrYXQgZnLDpW4gPGEgaHJlZj0iaHR0cHM6 Ly93aGF0aXN3b3Jrc3BhY2VvbmUuY29tL2JveGVyIj5Xb3Jrc3BhY2UgT05FIEJveGVyPC9hPjxz cGFuIGlkPSJkcmFmdC1icmVhayI+PC9zcGFuPjxicj4NCjxicj4NCjxkaXY+DQo8ZGl2IGNsYXNz PSJudWxsIiBkaXI9ImF1dG8iPkRlbiA1IGZlYnJ1YXJpIDIwMjAgMTg6MDY6MzAgQ0VUIEFsaXNz YSBDb29wZXIgJmx0O2FsaXNzYUBjb29wZXJ3LmluJmd0OyBza3Jldjo8YnIgY2xhc3M9Im51bGwi Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iYm9yZGVyLWxlZnQtc3R5 bGU6c29saWQ7Ym9yZGVyLXdpZHRoOjFweDttYXJnaW4tbGVmdDowcHg7cGFkZGluZy1sZWZ0OjEw cHg7IiBjbGFzcz0ibnVsbCI+DQo8ZGl2IGNsYXNzPSJudWxsIiBkaXI9ImF1dG8iPg0KPGRpdiBj bGFzcz0ibnVsbCI+DQo8ZGl2IGNsYXNzPSJudWxsIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdv cmQ7IGxpbmUtYnJlYWs6YWZ0ZXItd2hpdGUtc3BhY2UiPjxiciBjbGFzcz0ibnVsbCI+DQo8ZGl2 IGNsYXNzPSJudWxsIj48YnIgY2xhc3M9Im51bGwiPg0KPGRpdiBjbGFzcz0ibnVsbCIgcmVmPSI2 Njg1Ij4NCjxkaXYgaWQ9ImJ4LXF1b3RlLTY2ODUiIGNsYXNzPSJudWxsIj48c3BhbiBjbGFzcz0i bnVsbCI+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0ibnVsbCI+DQo8ZGl2IGNsYXNzPSJudWxsIj4NCjxkaXYgY2xhc3M9Im51bGwiPk9uIEZlYiA1 LCAyMDIwLCBhdCAxMDowMCBBTSwgQWxleGV5IE1lbG5pa292ICZsdDs8YSBocmVmPSJtYWlsdG86 YWFtZWxuaWtvdkBmYXN0bWFpbC5mbSIgY2xhc3M9Im51bGwiPmFhbWVsbmlrb3ZAZmFzdG1haWwu Zm08L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0ibnVsbCI+DQo8ZGl2IGNsYXNzPSJu dWxsIj4NCjxkaXYgY2xhc3M9Im51bGwiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7IGZv bnQtc2l6ZToxMnB4OyBmb250LXN0eWxlOm5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6bm9ybWFs OyBmb250LXdlaWdodDpub3JtYWw7IGxldHRlci1zcGFjaW5nOm5vcm1hbDsgdGV4dC1hbGlnbjpz dGFydDsgdGV4dC1pbmRlbnQ6MHB4OyB0ZXh0LXRyYW5zZm9ybTpub25lOyB3aGl0ZS1zcGFjZTpu b3JtYWw7IHdvcmQtc3BhY2luZzowcHg7IHRleHQtZGVjb3JhdGlvbjpub25lIj4NCk9uIFR1ZSwg RmViIDQsIDIwMjAsIGF0IDk6MjUgUE0sIEplZmZyZXkgWWFzc2tpbiB3cm90ZTo8YnIgY2xhc3M9 Im51bGwiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0ibnVsbCI+DQo8 ZGl2IGNsYXNzPSJudWxsIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJudWxsIj4NCjxkaXYgZGly PSJsdHIiIGNsYXNzPSJudWxsIj5PbiBUdWUsIEZlYiA0LCAyMDIwIGF0IDU6MzYgQU0gTWFnbnVz IFdlc3Rlcmx1bmQgdmlhIERhdGF0cmFja2VyICZsdDs8YSBocmVmPSJtYWlsdG86bm9yZXBseUBp ZXRmLm9yZyIgY2xhc3M9Im51bGwiPm5vcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnIg Y2xhc3M9Im51bGwiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj4NCjxibG9ja3F1b3RlIGNs YXNzPSJudWxsIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13 aWR0aDoxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjpyZ2Io MjA0LDIwNCwyMDQpOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgY2xhc3M9Im51bGwiPk1hZ251 cyBXZXN0ZXJsdW5kIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZv cjxiciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPmNoYXJ0ZXItaWV0 Zi13cGFjay0wMC0wNDogTm8gT2JqZWN0aW9uPGJyIGNsYXNzPSJudWxsIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0ibnVsbCI+PGJyIGNsYXNzPSJudWxsIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVs bCI+V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBh bmQgcmVwbHkgdG8gYWxsPGJyIGNsYXNzPSJudWxsIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVs bCI+ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVs IGZyZWUgdG8gY3V0IHRoaXM8YnIgY2xhc3M9Im51bGwiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJu dWxsIj5pbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8YnIgY2xhc3M9Im51bGwiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj48YnIgY2xhc3M9Im51bGwiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSJudWxsIj48YnIgY2xhc3M9Im51bGwiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxs Ij48YnIgY2xhc3M9Im51bGwiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj5UaGUgZG9jdW1l bnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6 PGJyIGNsYXNzPSJudWxsIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+PGEgcmVsPSJub3Jl ZmVycmVyIiBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWll dGYtd3BhY2svIiBjbGFzcz0ibnVsbCIgdGFyZ2V0PSJfQkxBTksiPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi13cGFjay88L2E+PGJyIGNsYXNzPSJudWxsIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+PGJyIGNsYXNzPSJudWxsIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0ibnVsbCI+PGJyIGNsYXNzPSJudWxsIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVs bCI+PGJyIGNsYXNzPSJudWxsIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxiciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPkNPTU1FTlQ6 PGJyIGNsYXNzPSJudWxsIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxiciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPjxiciBjbGFzcz0i bnVsbCI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPkkgaGF2ZSBzb21lIHF1ZXN0aW9ucy48 YnIgY2xhc3M9Im51bGwiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj48YnIgY2xhc3M9Im51 bGwiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj5Eb2VzIHRoZXJlIGV4aXN0IGFuIGVhc3kg d2F5IHRvIHJlc29sdmUgdGhlIGNsYXNoIGJldHdlZW4gdGhpcyBwcmltYXJ5IGFuZDxiciBjbGFz cz0ibnVsbCI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPm5vbi1nb2FsPyBQcmltYXJ5IGdv YWw6ICogVGhlIGFiaWxpdHkgdG8gY3JlYXRlIGFuIHVuc2lnbmVkIHNuYXBzaG90IG9mIGEgd2Vi PGJyIGNsYXNzPSJudWxsIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+cGFnZSB3aXRob3V0 IHRoZSBjb29wZXJhdGlvbiBvZiBpdHMgcHVibGlzaGVyLjxiciBjbGFzcz0ibnVsbCI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9Im51bGwiPjxiciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9Im51bGwiPk5vbi1nb2FsOjxiciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 Im51bGwiPiogQSB3YXkgdG8gZGlzdHJpYnV0ZSB0aGUgcHJpdmF0ZSBwb3J0aW9ucyBvZiBhIHdl YnNpdGUuIEZvciBleGFtcGxlLCBXUEFDSzxiciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9Im51bGwiPm1pZ2h0IGRlZmluZSBhIHdheSB0byBkaXN0cmlidXRlIGEgbWVzc2FnaW5n IGFwcGxpY2F0aW9uIGJ1dCB3b3VsZG4ndDxiciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9Im51bGwiPmRlZmluZSBhIHdheSB0byBkaXN0cmlidXRlIGluZGl2aWR1YWwgbWVzc2Fn ZXMgd2l0aG91dCBhIGRpcmVjdCBjb25uZWN0aW9uIHRvPGJyIGNsYXNzPSJudWxsIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0ibnVsbCI+dGhlIG1lc3NhZ2luZyBhcHBsaWNhdGlvbidzIG9yaWdpbiBz ZXJ2ZXIuPGJyIGNsYXNzPSJudWxsIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+PGJyIGNs YXNzPSJudWxsIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+U28gdGhlIGlzc3VlIEkgd29u ZGVyIG92ZXIsIGlzIHRoYXQgaWYgSSBhcyBhIHVzZXIgZGVjaWRlIHRvIHNuYXBzaG90IGE8YnIg Y2xhc3M9Im51bGwiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj53ZWItcGFnZSB0aGF0IGNv bnRhaW5zIHNvbWUgc2VydmVyLXNpZGUgZHluYW1pY2FsbHkgZ2VuZXJhdGVkIHJlc291cmNlcy4g VG8gbXk8YnIgY2xhc3M9Im51bGwiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj51bmRlcnN0 YW5kaW5nIHRoYXQgd291bGQgcmVzdWx0IGluIHRoYXQgZHluYW1pY2FsbHkgdXNlciBzcGVjaWZp YyBnZW5lcmF0ZWQ8YnIgY2xhc3M9Im51bGwiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj5j b250ZW50IHdvdWxkIGJlIGNhcHR1cmVkLiBIb3cgZG9lcyB0aGlzIHJlbGF0ZSB0byB0aGUgYWJv dmUgbm9uLWdvYWwuIE9yIGFyZTxiciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 Im51bGwiPnRoZXNlIHR3byBkaWZmZXJlbnQgdXNhZ2VzIG9mIHRoZSB0YXJnZXRlZCBzb2x1dGlv bi4gT25lIHRvIGFsbG93IHNuYXAgc2hvdGluZzxiciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9Im51bGwiPndoYXQgb25lIGFjdHVhbGx5IHByb3ZpZGVkLCBhbmQgYW5vdGhlciBh IGNvbmZpZ3VyYXRpb24gZm9yIGRpc3RyaWJ1dGluZyBhIHBhcnQ8YnIgY2xhc3M9Im51bGwiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj5vZiBhIHdlYi1zaXRlPzxiciBjbGFzcz0ibnVsbCI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPjxiciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9Im51bGwiPlRoZSBhYm92ZSB0aG91Z2h0IGxlYWQgdG8gdGhlIHF1ZXN0aW9uOiBJ cyBpdCBhdCBhbGwgcG9zc2libGUgdG8gcHJldmVudCBhIHVzZXI8YnIgY2xhc3M9Im51bGwiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj5mcm9tIHNoYXJpbmcgdGhlaXIgcHJpdmF0ZSBjb250 ZW50IGlmIHVzaW5nIHRoaXMgbWVjaGFuaXNtPyBXaWxsIHRoZSBwYWNrYWdlcjxiciBjbGFzcz0i bnVsbCI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPmJlIGFibGUgdG8gZGV0ZXJtaW5lIHdo YXQgaXMgcHJpdmF0ZSBhbmQgd2hhdCBpcyBub3Qgc28gdGhhdCB0aGUgdXNlciBjYW48YnIgY2xh c3M9Im51bGwiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj5zZWxlY3QgYmV0d2VlbiBhIHNu YXBzaG90IGFuZCBzaGFyaW5nIHRoZSBnZW5lcmFsIHBhcnQgb2YgYSB3ZWItc2l0ZT88YnIgY2xh c3M9Im51bGwiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8c3BhbiBpZD0iYngtcXVvdGUtZW5k LTY2ODUiIGNsYXNzPSJudWxsIj48L3NwYW4+DQo8ZGl2IGNsYXNzPSJudWxsIj48YnIgY2xhc3M9 Im51bGwiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj5UaGVzZSBhcmUgdGFsa2luZyBhYm91 dCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIDEpIHVuc2lnbmVkIGNvbnRlbnQsIDIpIHNpZ25lZCBj b250ZW50LCBhbmQgMykgc2lnbmVkIGFuZCBlbmNyeXB0ZWQgY29udGVudCwgd2hlcmUgSSB3YW50 ZWQgdG8gc2F5IHRoYXQgKDMpIGlzIG91dCBvZiBzY29wZS4gSXQncyBzYWZlIHRvIHNoYXJlIHVu c2lnbmVkIHBlcnNvbmFsaXplZCBjb250ZW50IHdpdGggdGhlIHBlcm1pc3Npb24NCiBvZiB3aG9l dmVyJ3MgZGF0YSBpdCBpcy4gSXQncyBub3Qgc2FmZSBmb3IgdGhlIHJlY2lwaWVudCB0byB1c2Ug c2lnbmVkIHBlcnNvbmFsaXplZCBjb250ZW50IGV2ZW4gd2l0aCB0aGUgcGVybWlzc2lvbiBvZiB0 aGUgb3duZXIgb2YgdGhlIGRhdGEuIFNvLCB0aGUgd29yZGluZyBvZiAmcXVvdDtBIHdheSB0byBk aXN0cmlidXRlIHRoZSBwcml2YXRlIHBvcnRpb25zIG9mIGEgd2Vic2l0ZS4mcXVvdDsgaXMgbWlz c2luZyBhbiBpbmRpY2F0aW9uIHRoYXQgaXQncyBhYm91dA0KIGRpc3RyaWJ1dGlvbiB3aGVuIHNp Z25lZCBhcyB0aGUgd2Vic2l0ZSBvciBpbiBhIHdheSB0aGF0IHRoZSBjbGllbnQgd2lsbCB0cnVz dCB0aGF0IGl0J3MgYXV0aGVudGljYWxseSBmcm9tIHRoZSB3ZWJzaXRlLjxiciBjbGFzcz0ibnVs bCI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPjxiciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSJudWxsIj48YnIgY2xhc3M9Im51bGwiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSJudWxsIj5GV0lXLCBJIHdhcyBhbHNvIGNvbmZ1c2VkIGFib3V0IHRoaXMg d2hlbiBJIHJlYWQgaXQsIHNvIEkgdGhpbmsgaXQgd291bGQgaGVscCB0byBjbGFyaWZ5LjwvZGl2 Pg0KPGRpdiBjbGFzcz0ibnVsbCI+PGJyIGNsYXNzPSJudWxsIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0ibnVsbCI+QWxpc3NhPC9kaXY+DQo8YnIgY2xhc3M9Im51bGwiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9Im51bGwiPg0KPGRpdiBjbGFzcz0ibnVsbCI+DQo8ZGl2IGNsYXNzPSJu dWxsIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSJudWxsIj4NCjxkaXYgY2xhc3M9 Im51bGwiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9Im51bGwiPg0KPGRpdiBjbGFzcz0ibnVsbCI+ DQo8ZGl2IGNsYXNzPSJudWxsIj5JIGRvbid0IGtub3cgYSB3YXkgZm9yIHRoZSBjbGllbnQgdG8g YXV0b21hdGljYWxseSBpZGVudGlmeSB3aGF0J3MgcHJpdmF0ZSBvciBub3Qgd2l0aG91dCBjb29w ZXJhdGlvbiBmcm9tIHRoZSB3ZWJzaXRlLiBJZiB0aGUgd2Vic2l0ZSBkb2VzIHByb3ZpZGUgYSBw YWNrYWdlLCBJIHRoaW5rIGl0J2QgbWFrZSBzZW5zZSBmb3IgY2xpZW50cyB0byBnaXZlIHRoZWly IHVzZXJzIHRoZSBhYmlsaXR5IHRvIHNhdmUgZWl0aGVyDQogdGhlIHdlYnNpdGUncyBwYWNrYWdl IG9yIGFuIHVuc2lnbmVkIHNuYXBzaG90IG9mIHdoYXQgdGhleSdyZSBjdXJyZW50bHkgbG9va2lu ZyBhdC48YnIgY2xhc3M9Im51bGwiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSJudWxsIiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0 aWNhOyBmb250LXNpemU6MTJweDsgZm9udC1zdHlsZTpub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDsgZm9udC13ZWlnaHQ6bm9ybWFsOyBsZXR0ZXItc3BhY2luZzpub3JtYWw7IHRleHQt YWxpZ246c3RhcnQ7IHRleHQtaW5kZW50OjBweDsgdGV4dC10cmFuc2Zvcm06bm9uZTsgd2hpdGUt c3BhY2U6bm9ybWFsOyB3b3JkLXNwYWNpbmc6MHB4OyB0ZXh0LWRlY29yYXRpb246bm9uZSI+DQo8 YnIgY2xhc3M9Im51bGwiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIiBzdHlsZT0iZm9udC1m YW1pbHk6SGVsdmV0aWNhOyBmb250LXNpemU6MTJweDsgZm9udC1zdHlsZTpub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDsgZm9udC13ZWlnaHQ6bm9ybWFsOyBsZXR0ZXItc3BhY2luZzpu b3JtYWw7IHRleHQtYWxpZ246c3RhcnQ7IHRleHQtaW5kZW50OjBweDsgdGV4dC10cmFuc2Zvcm06 bm9uZTsgd2hpdGUtc3BhY2U6bm9ybWFsOyB3b3JkLXNwYWNpbmc6MHB4OyB0ZXh0LWRlY29yYXRp b246bm9uZSI+DQpNYWdudXMsIGRvZXMgdGhlIGFib3ZlIGFkZHJlc3MgeW91ciBxdWVzdGlvbj8g SXMgYW55IGNoYW5nZSB0byB0aGUgdGV4dCBuZWVkZWQ/IElmIHllcywgY2FuIHlvdSBvciBKZWZm cmV5IHN1Z2dlc3QgdXBkYXRlZCB0ZXh0PzxiciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9Im51bGwiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7IGZvbnQtc2l6ZToxMnB4 OyBmb250LXN0eWxlOm5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6bm9ybWFsOyBmb250LXdlaWdo dDpub3JtYWw7IGxldHRlci1zcGFjaW5nOm5vcm1hbDsgdGV4dC1hbGlnbjpzdGFydDsgdGV4dC1p bmRlbnQ6MHB4OyB0ZXh0LXRyYW5zZm9ybTpub25lOyB3aGl0ZS1zcGFjZTpub3JtYWw7IHdvcmQt c3BhY2luZzowcHg7IHRleHQtZGVjb3JhdGlvbjpub25lIj4NCjxiciBjbGFzcz0ibnVsbCI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7IGZv bnQtc2l6ZToxMnB4OyBmb250LXN0eWxlOm5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6bm9ybWFs OyBmb250LXdlaWdodDpub3JtYWw7IGxldHRlci1zcGFjaW5nOm5vcm1hbDsgdGV4dC1hbGlnbjpz dGFydDsgdGV4dC1pbmRlbnQ6MHB4OyB0ZXh0LXRyYW5zZm9ybTpub25lOyB3aGl0ZS1zcGFjZTpu b3JtYWw7IHdvcmQtc3BhY2luZzowcHg7IHRleHQtZGVjb3JhdGlvbjpub25lIj4NCkJlc3QgUmVn YXJkcyw8YnIgY2xhc3M9Im51bGwiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIiBzdHlsZT0i Zm9udC1mYW1pbHk6SGVsdmV0aWNhOyBmb250LXNpemU6MTJweDsgZm9udC1zdHlsZTpub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDsgZm9udC13ZWlnaHQ6bm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzpub3JtYWw7IHRleHQtYWxpZ246c3RhcnQ7IHRleHQtaW5kZW50OjBweDsgdGV4dC10cmFu c2Zvcm06bm9uZTsgd2hpdGUtc3BhY2U6bm9ybWFsOyB3b3JkLXNwYWNpbmc6MHB4OyB0ZXh0LWRl Y29yYXRpb246bm9uZSI+DQpBbGV4ZXk8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DC7E7D258DDD48AC92685BDC6D60B976ericssoncom_-- From nobody Wed Feb 5 21:43:07 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBCA12001A; Wed, 5 Feb 2020 21:43:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan via Datatracker To: "The IESG" Cc: wpack-chairs@ietf.org, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Suresh Krishnan Message-ID: <158096778274.30460.17533714971397286479.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2020 21:43:02 -0800 Archived-At: Subject: [Wpack] Suresh Krishnan's No Objection on charter-ietf-wpack-00-07: (with COMMENT) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 05:43:03 -0000 Suresh Krishnan has entered the following ballot position for charter-ietf-wpack-00-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-wpack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This item seems oddly specific "* Allow the format to be used in self-extracting executables." but it is not clear to me that this is a property of the format. Can you clarify a bit what the format needs to do to meet this? Like Adam, Alissa, and Barry I would love to see a bit more elucidation of the "avoid centralization" aspect of the charter. From nobody Thu Feb 6 02:34:23 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF551207FF; Thu, 6 Feb 2020 02:34:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: wpack-chairs@ietf.org, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <158098525958.12315.5006920040676499715.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2020 02:34:19 -0800 Archived-At: Subject: [Wpack] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_chart?= =?utf-8?q?er-ietf-wpack-00-07=3A_=28with_COMMENT=29?= X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 10:34:19 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-wpack-00-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-wpack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Similar as Suresh, I'm uncertain how this goal would impact the format: "Allow the format to be used in self-extracting executables." Actually the list of goals seems to list a quite large variety of different aspects on various levels of depth. It not clear to me if all this needs to be in the charter. If there is agreement about what the group wants to do that good of course but (as the one mentioned above) if it's not clear how a goal would actually impact the technical work/format, it not fully clear to me why it is listed in the charter. From nobody Thu Feb 6 07:01:51 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0B61208AE; Thu, 6 Feb 2020 07:01:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: wpack-chairs@ietf.org, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158100130282.12276.7279804902074971471.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2020 07:01:42 -0800 Archived-At: Subject: [Wpack] Benjamin Kaduk's Block on charter-ietf-wpack-00-07: (with BLOCK and COMMENT) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 15:01:43 -0000 Benjamin Kaduk has entered the following ballot position for charter-ietf-wpack-00-07: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-wpack/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- The WPACK working group will develop a specification for a web packaging format that efficiently bundles multiple HTTP representations. It will also specify a way to optionally sign these resources such that a user agent can trust that they came from their claimed web origins. Key goals for WPACK are: A key feature of the modern web is that HTTPS is becoming almost universal: HTTPS provides not just encryption for the content but also integrity protection and source authentication, but we've had to put a fair bit of effort in to get to where we are. I'm not sure that we want to leave ourselves with a new baseline of "unsigned" and another fair bit of effort to get back to "most things have cryptographic protection". While I recognize that there are some use cases for WPACK where the origin may not be cooperative and the entity creating or distributing the packages needs to remain anonymous or pseudonymous, I don't think that precludes signing the resources in some way. What the exact semantics of such signing would be are, of course, not clear yet, but I'm reluctant to endorse a charter that describes the signing as just "optional". ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * The ability to create an unsigned snapshot of a web page without the cooperation of its publisher. Similarly, perhaps this would be "without a signature from its publisher". * Being extensible and crypto agile. Generally good things, though I'm curious if there's a particular direction(s) of extensibility in mind. * Support more-efficient signing of a single, possibly same-origin HTTP resource. More efficient than what? I am also confused about the "self-extracting executables" point that others mentioned. From nobody Thu Feb 6 10:24:18 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B9812010C; Thu, 6 Feb 2020 10:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=QC8k2W/I; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GooZwOvb 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 oyrwYsmqRWqf; Thu, 6 Feb 2020 10:24:14 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFAD1200D7; Thu, 6 Feb 2020 10:24:14 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 07EC7220E7; Thu, 6 Feb 2020 13:24:14 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Thu, 06 Feb 2020 13:24:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=lFuHIU4RBFACxITm4KLZ4Ej2HE5e66c 3GiAdA3x1xXc=; b=QC8k2W/IzAF9eGx/VmG/OeQA/t+HT2AZ9etgY45ixdrfAJ1 i4M0G00cWdUOMKoa+WAqOlWzpmDqUHAs8vzU8DGLX8Onsba0z7SPJVp3zyu+U2x9 /fHaNc6FaV3sNJhmGtm78V0li3biXtnbof6ZOMZaIiQt3PEKVBA1V7qvn6BOWyRe BXrNZP+KLmiAcSD3VAbzJW8mmwhrgm8xbyNIOB5uZJZYrHs5awLWXG0iDqb7bA7I kFJeG9hY9nlDh9xNHuzyp2vrkC98jswf48srzS9QCAwe5CmQiNPtvvxNvCuSUBHw cqC0y04jLnBfnnp4TW3rf4ieG7WnAR6CeQ+7qxQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=lFuHIU 4RBFACxITm4KLZ4Ej2HE5e66c3GiAdA3x1xXc=; b=GooZwOvbhtcbhcYTZoSVkb 8RoUesJ6h5SBevorr05JQz7AqGI9wqkkEfYgEidBe6ktqupDYa4+BX87TJ7Id7i9 bwYIhLRUzn/vOQOvkUqYSrIdrK4o0C+h8epXa6vQ9oy6W7xI5vfhEw/vTeAubJ0b RHzVac4rc9kYYT5gPezUJvyuJaWz3FfJ1pDbJT8+PvZLP44lfIAbMppN+sfyT+mC DZvQ2QdGyG4WsortPgHnH4TOR09fhhYhTbRx/Pvi8jvSq2OMFFt4x8BtRicX+7zy BsXLqxRsjszntoApq/2IWD6CCflgJyXv3vuM6koxn9a8QWHvZCTbZGCp6zm9rihQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheefgdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuffhomhgrihhnpehivghtfhdrohhrghdphhhtthhprhgvphhrvghsvghnthgr thhiohhnshdrihhtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2FF0F660069; Thu, 6 Feb 2020 13:24:13 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <782c56cb-6d2a-49bb-bb64-a96b920aaf86@www.fastmail.com> In-Reply-To: <158100130282.12276.7279804902074971471.idtracker@ietfa.amsl.com> References: <158100130282.12276.7279804902074971471.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2020 18:23:51 +0000 From: "Alexey Melnikov" To: "Benjamin Kaduk" , "Jeffrey Yasskin" Cc: wpack@ietf.org, wpack-chairs@ietf.org, "The IESG" Content-Type: text/plain Archived-At: Subject: Re: [Wpack] =?utf-8?q?Benjamin_Kaduk=27s_Block_on_charter-ietf-wpack?= =?utf-8?q?-00-07=3A_=28with_BLOCK_and_COMMENT=29?= 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, 06 Feb 2020 18:24:16 -0000 Hi Ben, On Thu, Feb 6, 2020, at 3:01 PM, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > charter-ietf-wpack-00-07: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-wpack/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > The WPACK working group will develop a specification for a web packaging > format that efficiently bundles multiple HTTP representations. It will also > specify a way to optionally sign these resources such that a user agent can > trust that they came from their claimed web origins. Key goals for WPACK are: > > A key feature of the modern web is that HTTPS is becoming almost > universal: HTTPS provides not just encryption for the content but also > integrity protection and source authentication, but we've had to put a > fair bit of effort in to get to where we are. I'm not sure that we want > to leave ourselves with a new baseline of "unsigned" and another fair > bit of effort to get back to "most things have cryptographic > protection". While I recognize that there are some use cases for WPACK > where the origin may not be cooperative and the entity creating or > distributing the packages needs to remain anonymous or pseudonymous, I > don't think that precludes signing the resources in some way. What the > exact semantics of such signing would be are, of course, not clear yet, > but I'm reluctant to endorse a charter that describes the signing as > just "optional". I think "optional" is because a particular bundle might be generated by somebody other than the publisher. I don't think the intent is to encourage publishers not to sign. So how about changing "specify a way to optionally sign these resources" to "specify a way for publishers to sign these resources". So basically to drop "optionally" and clarify who this sentence applies to. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * The ability to create an unsigned snapshot of a web page without the > cooperation of its publisher. > > Similarly, perhaps this would be "without a signature from its > publisher". > > * Being extensible and crypto agile. > > Generally good things, though I'm curious if there's a particular > direction(s) of extensibility in mind. I don't think such details belong to the charter. > * Support more-efficient signing of a single, possibly same-origin HTTP > resource. > > More efficient than what? Jeffrey, could you expand on what was intended here? > I am also confused about the "self-extracting executables" point that > others mentioned. I suggest we drop it, because it is not clear how useful this goal is. I assume pretty much any data structure can be used by a self-extracting executable :-). Best Regards, Alexey From nobody Thu Feb 6 10:36:58 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB25120142; Thu, 6 Feb 2020 10:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=N9+Bs7xr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZmvrhjUu 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 92zyXQkJ5Zk7; Thu, 6 Feb 2020 10:36:50 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5063F120942; Thu, 6 Feb 2020 10:36:50 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A8D722012F; Thu, 6 Feb 2020 13:36:49 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Thu, 06 Feb 2020 13:36:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=uS6ULpSs4y1A2ugpOzBuxFrUJpqUp4p fHl8GottV16s=; b=N9+Bs7xrhkAvaTx6ljHxUaayNS7F5x7p0Gd94U/MWgXboAs ox79kKX+iKLitatnBtgZ+UbZIaaEuP39As6V37wwlstKJZyp2JKt7sKgyxURzRbO NLGXpVeNE4HxzW4waUcig2/Jn0dXiKHRzsEURz/hYzdJVsaLCC1RM+9c6MU7q9Gu M0EcFH45Nmc4CChqBJ8MByTvxdVgFI4+Yfi/T7MxBQRQVh4mF/gdXxcnLJ0VLn5O WeFVs/pmDkN7fxYoGsEO/yO2UaM4CHl7KCCEScvXlYKV/Dzbd0+Fi1ByPskMDdDE 58UnKPSM+smC2ayxWvNKKip33XXPBZQxd2y1sjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=uS6ULp Ss4y1A2ugpOzBuxFrUJpqUp4pfHl8GottV16s=; b=ZmvrhjUuK4C994BwGfjIzO H2lSv+R8Wfxzw4T5o9eyNXt8/AU+CKxjiDywCR0Q+jhE/4wxx4mY8WsMgMsR6VW8 r4hZG8J63gpV7Xf8FzYyZLtZrvPMyVAIxy72YZxdlYdqCZTcOVc0aro2JQDmgCfO QSvoWfsQXkLYwN6wfBr7QRM3GLIYjiwkaaAgtBPs73H4gVzk+fJZPzcKohV7uXFW mvj9R6ehBjSeRbh/VvF/R3T6KKgOlvmSGiAuN2RfpUtgkb8tu82l+LVh5apfYK4l LjdjVhXu7CPYWbZvoq4/lsvjYy5XaKjpBRKcouSp93KdvjYsfTwC4rgylL/aVbMg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheefgdduudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 69F2C660065; Thu, 6 Feb 2020 13:36:49 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <158096778274.30460.17533714971397286479.idtracker@ietfa.amsl.com> References: <158096778274.30460.17533714971397286479.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2020 18:36:29 +0000 From: "Alexey Melnikov" To: "Suresh Krishnan" , "The IESG" Cc: wpack@ietf.org, wpack-chairs@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] =?utf-8?q?Suresh_Krishnan=27s_No_Objection_on_charter-ie?= =?utf-8?q?tf-wpack-00-07=3A_=28with_COMMENT=29?= 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, 06 Feb 2020 18:36:56 -0000 Hi Suresh, On Thu, Feb 6, 2020, at 5:43 AM, Suresh Krishnan via Datatracker wrote: > Suresh Krishnan has entered the following ballot position for > charter-ietf-wpack-00-07: No Objection > This item seems oddly specific > > "* Allow the format to be used in self-extracting executables." > > but it is not clear to me that this is a property of the format. Can you > clarify a bit what the format needs to do to meet this? I deleted it, I don't think this helps in the charter. > Like Adam, Alissa, and Barry I would love to see a bit more elucidation of the > "avoid centralization" aspect of the charter. I deleted this as well, as it read more like motherhood and apple pie. Best Regards, Alexey From nobody Thu Feb 6 10:48:52 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EF81200E9 for ; Thu, 6 Feb 2020 10:48:47 -0800 (PST) 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.25, 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 DQbksO-BCLl9 for ; Thu, 6 Feb 2020 10:48:45 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 24B8E1200EC for ; Thu, 6 Feb 2020 10:48:45 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id d9so5291984qte.12 for ; Thu, 06 Feb 2020 10:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8wJWGQj/QdDhhHSaASGdf5jWy++x0FMn2TEFmasKfqg=; b=Q20sFsBxVIHUmfgC7F1cvIH7aaqNpaMi//9niHhUwFT81qW8izSlXuTm90ZzUyvyUx oEpdbAjGnROOEqD+OzUAyM7VOiEnOYGP8k3AZyAWj3mMQv1jadVq8MAql0uLgr4ls9jg XdeB1ra6HJOA31oJXn8+cN4jfKEjKKIp4lmBY= 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=8wJWGQj/QdDhhHSaASGdf5jWy++x0FMn2TEFmasKfqg=; b=FRu2bqH5XkQvI3XO0d488rGIOxzJSVzqmDcQIeaIJpOVeOG9/8DPch1ly8zLfQE3UR cMZAH0C7Pz5bC6RktH2BXgkeXLn0z73iPClZirUBtMMkuWJr4rbqmjncQVsMm0qA+r01 fl1JWGArRphWMI9xpMt81ZbxTBfN6y8SI0FCe33BdGU0K6eUga3PmaKsU1JiaD/M4fQ9 f2qg1EP97wJjDx/gaKTOKxf8RuJ3r0QvB5kHi7Z4Duc2woccbi6fk/Wx67iMHmmvby8n +8staVwbLArBf49wxz3y1M76/q3tG62SZ/QsE2fJoN/FsJax+hKNa5LnyC1I2Wf02Zyn xBaw== X-Gm-Message-State: APjAAAXsuNACF3ePFYntUNimMQHsNarNj6hS//sRDdki90tKunP7jppD Z1s3vjxAybxmou/1dfz/XZW3te8x24wcQhsqjINcZg== X-Google-Smtp-Source: APXvYqxJRTm5No3n+0rA/77mnDSKQs563L9ao77ElTcHf44GMHMxjyezl9+SFrQXU02X0H5si1bdzeo4jVdAU2gl+7Q= X-Received: by 2002:ac8:42c6:: with SMTP id g6mr4000318qtm.250.1581014923715; Thu, 06 Feb 2020 10:48:43 -0800 (PST) MIME-Version: 1.0 References: <158100130282.12276.7279804902074971471.idtracker@ietfa.amsl.com> In-Reply-To: <158100130282.12276.7279804902074971471.idtracker@ietfa.amsl.com> From: Jeffrey Yasskin Date: Thu, 6 Feb 2020 10:48:32 -0800 Message-ID: To: Benjamin Kaduk Cc: The IESG , wpack@ietf.org, wpack-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Wpack] Benjamin Kaduk's Block on charter-ietf-wpack-00-07: (with BLOCK and COMMENT) 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, 06 Feb 2020 18:48:47 -0000 Sorry I'm behind on some of the other comments. On Thu, Feb 6, 2020 at 7:01 AM Benjamin Kaduk via Datatracker wrote: > > Benjamin Kaduk has entered the following ballot position for > charter-ietf-wpack-00-07: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-wpack/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > The WPACK working group will develop a specification for a web packaging > format that efficiently bundles multiple HTTP representations. It will also > specify a way to optionally sign these resources such that a user agent can > trust that they came from their claimed web origins. Key goals for WPACK are: > > A key feature of the modern web is that HTTPS is becoming almost > universal: HTTPS provides not just encryption for the content but also > integrity protection and source authentication, but we've had to put a > fair bit of effort in to get to where we are. I'm not sure that we want > to leave ourselves with a new baseline of "unsigned" and another fair > bit of effort to get back to "most things have cryptographic > protection". While I recognize that there are some use cases for WPACK > where the origin may not be cooperative and the entity creating or > distributing the packages needs to remain anonymous or pseudonymous, I > don't think that precludes signing the resources in some way. What the > exact semantics of such signing would be are, of course, not clear yet, > but I'm reluctant to endorse a charter that describes the signing as > just "optional". I think it would be fine (wouldn't break any use cases) to require that the package be signed by *some* key, but that signature is only useful to a recipient if they can map it to some identity that they recognize. Most users don't have a public key with such an identity, so it didn't seem useful to require them to generate a key just to save a web page into a package. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * The ability to create an unsigned snapshot of a web page without the > cooperation of its publisher. > > Similarly, perhaps this would be "without a signature from its > publisher". That sounds fine to me. > * Being extensible and crypto agile. > > Generally good things, though I'm curious if there's a particular > direction(s) of extensibility in mind. I was thinking primarily of dealing with algorithms that get broken, and that's one motivation for allowing multiple signatures on a resource. For example, we know that post-quantum crypto is coming, and during the migration to it a signer might want to provide signatures with both an elliptic curve algorithm and a post-quantum algorithm, to be compatible with more clients. > * Support more-efficient signing of a single, possibly same-origin HTTP > resource. > > More efficient than what? A multi-resource bundle has some overhead to support the ability to include multiple resources. The current "signed exchange" format is a little smaller because it doesn't need to support more than one resource, and I wanted the group to be able to keep that optimization. I'm not certain we'll wind up wanting to keep it. > I am also confused about the "self-extracting executables" point that > others mentioned. This drove the inclusion of the package length at the end of the package format, and didn't otherwise change the format. Including the trailing length allows one to concatenate an extraction executable with a package without needing the executable to know its own length. It was a request from, I think, someone who worked on Electron. Jeffrey From nobody Thu Feb 6 11:31:56 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2011200F3; Thu, 6 Feb 2020 11:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTuPlLBX9_Sk; Thu, 6 Feb 2020 11:31:50 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 AA3A01200B2; Thu, 6 Feb 2020 11:31:50 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id j7so2747045plt.1; Thu, 06 Feb 2020 11:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=9Pwmzl7mytly+i3ko6nCDjrQfjtopefK8BTU4U+l+28=; b=HetGNDMOxiFzbpkyZVhy5ORnIto295C8PjQdvx+inKkveiQU/ASn/DH7F1kGn72DB8 iSPEbXfziH8rq/s9MxGPesnKsNWJQY1TqAskGnMLGGu4WrhBxV9nIFKuHLDAUwrLa1OK fCU8S0CtcYmkXZAfbZoWlVafGO8/xrPX2sd3mgv0MKx61TfczQx/FKXJcTkQs9W1wDlj X28UArmCAsY9ON5e1e2D0VDQ/qmX6vQc3ZzRzDfn7zPYEVSwyhSec3iRTK2mqU8j4WR0 kscMSzxfDUFvdYBG1uCNHp22yOUZxR3TSAygWLcaTJzqCKJZ2Bkw2wk0gRBGYBiR+tMX YSjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=9Pwmzl7mytly+i3ko6nCDjrQfjtopefK8BTU4U+l+28=; b=XZtgebwdR/2pKgr309zXLGiHe66x3XBlV2IJqYTjLCoT033K9KXiNpMi/VtJuuHL+D /HdYW42Cd2HcaiRzK+gZzZs7UIepNSGnWh4FKqI1Rq+loO/Y2Ro/MCpqDjauxrHn96LS rApERPrMCb9P1M4t0wKyYCr35g0emfrqFF+utuRtHMcYrbzWa5ROlpIVJDS2TKlHsnnL /v1yhEymkZB173jwNKVKwcolA3BkqT2Ljf+gqZXBgg0WwTFrqBsbQkD+Amw2/BJeyKNS bqcLzOKmbl77vI3bq9Q2vJquuK8qKkO8RyoMqh/WUzG9NR+iCrbMKWMudKOTP7a3SVt2 QNYQ== X-Gm-Message-State: APjAAAX0NLcqVevgvvuNx5nf95ZJrm4WgSHPaYgFqqYAhzhk3hMOwuH3 LBfIbTetl/tgp/ZMjpY8b6alxsxO X-Google-Smtp-Source: APXvYqxWExJZrsxy8+yHWuxL1SNneykrMn2hmfyGBMZGWne9jkuI4gcszL2B+v0JCzw0T+2NJIXCeg== X-Received: by 2002:a17:90b:3004:: with SMTP id hg4mr6512025pjb.52.1581017509403; Thu, 06 Feb 2020 11:31:49 -0800 (PST) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id c19sm183745pfc.144.2020.02.06.11.31.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2020 11:31:47 -0800 (PST) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: Cc: Date: Thu, 6 Feb 2020 11:31:46 -0800 Message-ID: <007b01d5dd24$127e5cd0$377b1670$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdXdJBD4qRE1z7l3T5mbZ7NL5zUkyQ== Content-Language: en-us Archived-At: Subject: [Wpack] wpack charter X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 19:31:52 -0000 > Actually the list of goals seems to list a quite large variety of different aspects on various levels of depth. > It not clear to me if all this needs to be in the charter. If there is agreement about what the group wants > to do that good of course but (as the one mentioned above) if it's not clear how a goal would actually impact > the technical work/format, it not fully clear to me why it is listed in the charter. Perhaps some guidelines on charter-writing would be useful? The purpose of a charter is to establish scope (as an upper bound) and success (as a lower bound)., as well as starting points. But most of the requirements in charter-ietf-wpack are goals which are not orthogonal and can be In conflict. And "Efficient" "agile" "as close as practical" and the like don't seem to either establish scope or success criteria, but are design metrics but will need to be traded off. I'd suggest taking the "Key goals for WPACK are" and "the following goals are out of scope" Putting them in an Internet Draft (or combine them with the use cases document). Personally, I don't see the reason not to publish the use cases and goals as an RFC with an early milestone. I think you'll get better review to spend the time to do the work to evaluate the goals across use cases. The charter mentions several documents that are not listed with URLs -- LarryMasinter.net From nobody Thu Feb 6 11:43:58 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F02B1200EC for ; Thu, 6 Feb 2020 11:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW_vSATs94Q1 for ; Thu, 6 Feb 2020 11:43:53 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB5E1200F3 for ; Thu, 6 Feb 2020 11:43:53 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id d5so45788qto.0 for ; Thu, 06 Feb 2020 11:43:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=SdTKpk01/1Bisqa/b9aKR/Dyu0VS0jqQJno6AmbuS04=; b=i+pD2j0df0LD7cDKgrYYF7zIo2tYE02kNITKFcS58wD7MCpHqI1PaZf4wXv5ZtpZbl P+GBrewrtCmwxfxIskCEK6+4QSTSWxxQrMaAQrRKwI1FoNNDQJauAJ85J8jz0b4Dxpxi L49M94AsNgb3EAJzHmQs1UAb05ba4E3xBVD44= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=SdTKpk01/1Bisqa/b9aKR/Dyu0VS0jqQJno6AmbuS04=; b=sEcFJnxVCv9ZOVVQg+zfZOLeklRPA9fVgPiVXdfisOp1RXpo2cENu00gHWojscxST2 k/VgJf7zMVV0A+BPgAwneC85SsF5M1/WrHTMtLuMxq82jAnsWCmZJk9MPZs3rz8Mlj80 53FwcDnVki6r+RqWmPrmd2tz4xQCGiKIdWprAmFNckiUOQ/U9Esdx7OyytRpSQ8rx0Xy U5o741gWc8b0LhkSie184Z/l866ehgb/iqQe+JCYHQLYgLyoGUC4Y0cO/Wl0HB8o8FiL hKJ4hdhds9V+8ScO1PLLmXLca6FIGY3V7gPpkv2ZPWi6RtVrJ7IzVjmTX64KbAbcfrgW bteA== X-Gm-Message-State: APjAAAXB1JvtPSSQwUvZAdkK7+1pKzcRFFo7P/CUcdEPOgKV0HS+zIJF /aKDqgJd3Wltr4Ans0LN3cj4WQ== X-Google-Smtp-Source: APXvYqzoSfoxkOJsmTTFJZJ17Z/oZ0ZnwNLWug/9JjyGZF3kUxi9b0+c9+FA74iwJ4/nSz1d78C7sw== X-Received: by 2002:aed:3384:: with SMTP id v4mr4123782qtd.58.1581018231817; Thu, 06 Feb 2020 11:43:51 -0800 (PST) Received: from [5.5.33.211] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id 4sm152688qki.51.2020.02.06.11.43.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Feb 2020 11:43:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Sean Turner Mime-Version: 1.0 (1.0) Date: Thu, 6 Feb 2020 20:43:48 +0100 Message-Id: References: Cc: Benjamin Kaduk , The IESG , wpack@ietf.org, wpack-chairs@ietf.org In-Reply-To: To: Jeffrey Yasskin X-Mailer: iPhone Mail (17D50) Archived-At: Subject: Re: [Wpack] Benjamin Kaduk's Block on charter-ietf-wpack-00-07: (with BLOCK and COMMENT) 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, 06 Feb 2020 19:43:54 -0000 Sent from my iPhone > On Feb 6, 2020, at 19:48, Jeffrey Yasskin wrote: >=20 > t sounds fine to me. >=20 >> * Being extensible and crypto agile. >>=20 >> Generally good things, though I'm curious if there's a particular >> direction(s) of extensibility in mind. >=20 > I was thinking primarily of dealing with algorithms that get broken, > and that's one motivation for allowing multiple signatures on a > resource. For example, we know that post-quantum crypto is coming, and > during the migration to it a signer might want to provide signatures > with both an elliptic curve algorithm and a post-quantum algorithm, to > be compatible with more clients. I think it is fine to keep this, but since we have BCP 201 do we strictly ne= ed to include this? spt= From nobody Thu Feb 6 12:06:28 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B848120106 for ; Thu, 6 Feb 2020 12:06:26 -0800 (PST) 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.25, 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 WQO4kC8h3IBC for ; Thu, 6 Feb 2020 12:06:25 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 DEBF71200FF for ; Thu, 6 Feb 2020 12:06:24 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id d11so443481qko.8 for ; Thu, 06 Feb 2020 12:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ci/zSr1r9TL9ksdURI3Iwn9I9iMh9CGenZhcSXLdQhI=; b=FjnN3xfxMuN9MZoatffQ9REFHi5bUxoWLu/4/nHmHp5wG6yy6KlCkLgL62fdvrignw Tkab7J28BYEF1oT6JtUCOz8dChcT8/jM2XirVt60quSszcmyf1Ai408UmaacMFgw+LD8 FEHueQw6lMFN3fYVzZLIIuqBELh51QfRihMU0= 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=ci/zSr1r9TL9ksdURI3Iwn9I9iMh9CGenZhcSXLdQhI=; b=hkl1B/idZ0g3UyukmB1VwXEQ2qHoWb0sCsqtNZhYQ9Q0sSmLo7cijg0gzQMo+nxVXk UAd9sVmiHmqSt4QBtoVCZ3N7Mo1bvmAfAa6wCvOQDi/4AbG0vJig3JJoUTI0jquGsWCD /LO6TXOFF8gGDWK5cBTyKuig+tVVO10lpkC9KgZ6wBH8otQq95Uq4zOsdiQjR7e9LvFR 0ZAfLL+OdkYbqjgO6hac/rjVpliqd3VVQYzdr6Ldfgyfjxac86AMjtekQee4c3+OY+M+ fJPQL4YJdfnQvpid/q+HmBzB4rSJX+XmGg43ot2DVDpUmiOvnXDKL4kGa22Ca33Aqyxg /Q8Q== X-Gm-Message-State: APjAAAV+tCI3/AAhk1Q2qIvQ21jmXNaKEfF8Ju180Xb6ZmgPNoHW/SNe NkttREjq7VOZNL7vG/gkrMPNeUNnTkfki7yZbn2SIGtP X-Google-Smtp-Source: APXvYqzWjXpBy3SyvMcDL61Pe/drYzQljTJyLe7BJnPTAMv1h8FOUcRGAyouCgk1w8GlK5AotCXK+QsIFPQR+AF6aMs= X-Received: by 2002:a37:63c9:: with SMTP id x192mr3873121qkb.447.1581019583566; Thu, 06 Feb 2020 12:06:23 -0800 (PST) MIME-Version: 1.0 References: <158092389711.12848.12402128420849051568.idtracker@ietfa.amsl.com> In-Reply-To: <158092389711.12848.12402128420849051568.idtracker@ietfa.amsl.com> From: Jeffrey Yasskin Date: Thu, 6 Feb 2020 12:06:12 -0800 Message-ID: To: Alissa Cooper Cc: The IESG , wpack@ietf.org, wpack-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Wpack] Alissa Cooper's No Objection on charter-ietf-wpack-00-07: (with COMMENT) 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, 06 Feb 2020 20:06:26 -0000 On Wed, Feb 5, 2020 at 9:31 AM Alissa Cooper via Datatracker wrote: > > Alissa Cooper has entered the following ballot position for > charter-ietf-wpack-00-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-wpack/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "* A low likelihood that the new format increases centralization or power > imbalances on the web. See discussion of this in > " > > Unlike the other goals listed, it's hard to see how this is actionable. Will > the WG make design decisions differently whether this is in the charter or not? > If this working group were designing a system architecture or a protocol with > an architecture that implied relationships prone to centralization would need > to be created or strengthened for deployment purposes, perhaps this would be an > appropriate goal. But the scope here is to specify a format that will be used > in the context of the existing web with all of its existing centralization and > power imbalances derived from the economic properties of the businesses > operating within it. To me, stating this goal is sort of like saying we'll try > not to throw kindling on a forest fire that is already propelled by gale force > winds. We can say we'll do that, but what actually happens won't be determined > by whether we do it or not. One particular design decision that this goal affects is whether publishers can't (the current proposal), can, or must specify a list of distributors who can redistribute their signed packages. Picking "must" in particular would encourage centralization in redistributors. There are some upsides too, of course. It's possible that the economic properties of the existing internet are so large as to make irrelevant any choices this particular format makes, but Adam and Barry seem to disagree. It's also possible that this goal is so "motherhood and apple pie" that we don't need to say it explicitly. I'll certainly keep paying attention to it regardless of whether it's in the charter. Jeffrey From nobody Thu Feb 6 17:33:12 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E357912003F; Thu, 6 Feb 2020 17:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCV6texXbvpn; Thu, 6 Feb 2020 17:33:09 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 159E212001E; Thu, 6 Feb 2020 17:33:08 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0171X4Ys027046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 6 Feb 2020 20:33:06 -0500 Date: Thu, 6 Feb 2020 17:33:03 -0800 From: Benjamin Kaduk To: Jeffrey Yasskin Cc: The IESG , wpack@ietf.org, wpack-chairs@ietf.org Message-ID: <20200207013303.GL14382@kduck.mit.edu> References: <158100130282.12276.7279804902074971471.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Wpack] Benjamin Kaduk's Block on charter-ietf-wpack-00-07: (with BLOCK and COMMENT) 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, 07 Feb 2020 01:33:11 -0000 On Thu, Feb 06, 2020 at 10:48:32AM -0800, Jeffrey Yasskin wrote: > Sorry I'm behind on some of the other comments. > > On Thu, Feb 6, 2020 at 7:01 AM Benjamin Kaduk via Datatracker > wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > charter-ietf-wpack-00-07: Block > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-wpack/ > > > > > > > > ---------------------------------------------------------------------- > > BLOCK: > > ---------------------------------------------------------------------- > > > > The WPACK working group will develop a specification for a web packaging > > format that efficiently bundles multiple HTTP representations. It will also > > specify a way to optionally sign these resources such that a user agent can > > trust that they came from their claimed web origins. Key goals for WPACK are: > > > > A key feature of the modern web is that HTTPS is becoming almost > > universal: HTTPS provides not just encryption for the content but also > > integrity protection and source authentication, but we've had to put a > > fair bit of effort in to get to where we are. I'm not sure that we want > > to leave ourselves with a new baseline of "unsigned" and another fair > > bit of effort to get back to "most things have cryptographic > > protection". While I recognize that there are some use cases for WPACK > > where the origin may not be cooperative and the entity creating or > > distributing the packages needs to remain anonymous or pseudonymous, I > > don't think that precludes signing the resources in some way. What the > > exact semantics of such signing would be are, of course, not clear yet, > > but I'm reluctant to endorse a charter that describes the signing as > > just "optional". > > I think it would be fine (wouldn't break any use cases) to require > that the package be signed by *some* key, but that signature is only > useful to a recipient if they can map it to some identity that they > recognize. Most users don't have a public key with such an identity, > so it didn't seem useful to require them to generate a key just to > save a web page into a package. This seems like a question that should be decided by a WG and not at charter time! Alexeys suggestion of "a way for publishers to sign these resources" (or perhaps even just "a way to sign these resources"?) is probably a good way forward. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > * The ability to create an unsigned snapshot of a web page without the > > cooperation of its publisher. > > > > Similarly, perhaps this would be "without a signature from its > > publisher". > > That sounds fine to me. > > > * Being extensible and crypto agile. > > > > Generally good things, though I'm curious if there's a particular > > direction(s) of extensibility in mind. > > I was thinking primarily of dealing with algorithms that get broken, > and that's one motivation for allowing multiple signatures on a > resource. For example, we know that post-quantum crypto is coming, and > during the migration to it a signer might want to provide signatures > with both an elliptic curve algorithm and a post-quantum algorithm, to > be compatible with more clients. Sean's point is a good one, though it may still be worth mentioning extensibility in its own right. > > * Support more-efficient signing of a single, possibly same-origin HTTP > > resource. > > > > More efficient than what? > > A multi-resource bundle has some overhead to support the ability to > include multiple resources. The current "signed exchange" format is a > little smaller because it doesn't need to support more than one > resource, and I wanted the group to be able to keep that optimization. > I'm not certain we'll wind up wanting to keep it. So this could be summarized as "optimizations in encoding and processing when only a single resource (as opposed to a collection thereof) is being packaged"? > > I am also confused about the "self-extracting executables" point that > > others mentioned. > > This drove the inclusion of the package length at the end of the > package format, and didn't otherwise change the format. Including the > trailing length allows one to concatenate an extraction executable > with a package without needing the executable to know its own length. > It was a request from, I think, someone who worked on Electron. Ah, that helps with understanding, though it's perhaps a bit more detailed of a point than might be expected in a charter. Thanks, Ben From nobody Fri Feb 7 03:12:30 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0B5120866; Fri, 7 Feb 2020 03:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=MlSzOxlr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zfd+O8yX 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 i-m7e6gh1ezk; Fri, 7 Feb 2020 03:12:26 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D62120241; Fri, 7 Feb 2020 03:12:26 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1C4A821EA7; Fri, 7 Feb 2020 06:12:25 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Fri, 07 Feb 2020 06:12:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=F1J5sFO4YTHsOS82fkBSYgTOnaJCBBc tLOTCsPTSK5k=; b=MlSzOxlrnqlEjz+7glHPLjaWLLZdLPDCND7bgsNnxLWU4BS vYBr5hcejbjPH9h8VOpVhTNXiT9GHwx0qTmFUEITqTpyf15wc6Qx1OPFbuwImmWU ekISDotoCA1tseKnqxcrpmfUhIvqyfw7szEMOxPbrEgrhXHrN6s49Bf7AR29RcqD ZKymejtRCCjgrhSQhnuX793z1LDUmhQ6u7ep+g2QOS1zff9ujo6dnLecxXOJrHN4 gstKbXhZcDbPAjL5OUg08tX/UrMSQpf6KIQQ3iucX6rCexLwAvhxpA7XVCeFdhjI A6iubagOPUzTYRkL9yFuHG7FMFHorSVCZR2nsuQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=F1J5sF O4YTHsOS82fkBSYgTOnaJCBBctLOTCsPTSK5k=; b=zfd+O8yXaFF2zsGiKvj3Qf uu6OqAokAeVUCfhgn+IC3TbJiH8T3hfqSd0BchVGqXEQzuJ0PvvcpqV+RRfsNGMW IKY6IYwhPC5gkjhRMAc3Ho8N0zY6TinmLPEkLQK9kx/ZEQb+VrR2H9LJQpVzuFCY TyuWWelDxzdFqtk+dwncYDiHW5R9MjCALvxhTbZsCfW1z4g/V6WE0ElKZgPcZ/tA BXYv9ZZZ34ReEBimfdFITo0M+S9tmAI7C6/luWwCWvZRChVmsrsEn3iyc1Q+6tQO hDToceYxG6cBGPLDpMH1dm/Z+RJOoeS/ku9Z0X3dheYuQ4n8wP2MlqkPyVGiZuZw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheehgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucffohhmrghinhepihgvthhfrdhorhhgpdhhthhtphhrvghprhgvshgvnhhtrght ihhonhhsrdhithenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 85003660065; Fri, 7 Feb 2020 06:12:24 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <680be1d6-3fd5-46a3-b51f-1dda32664c0c@www.fastmail.com> In-Reply-To: <20200207013303.GL14382@kduck.mit.edu> References: <158100130282.12276.7279804902074971471.idtracker@ietfa.amsl.com> <20200207013303.GL14382@kduck.mit.edu> Date: Fri, 07 Feb 2020 11:11:45 +0000 From: "Alexey Melnikov" To: "Benjamin Kaduk" , "Jeffrey Yasskin" Cc: wpack@ietf.org, wpack-chairs@ietf.org, "The IESG" Content-Type: text/plain Archived-At: Subject: Re: [Wpack] =?utf-8?q?Benjamin_Kaduk=27s_Block_on_charter-ietf-wpack?= =?utf-8?q?-00-07=3A_=28with_BLOCK_and_COMMENT=29?= 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, 07 Feb 2020 11:12:28 -0000 Hi Ben, On Fri, Feb 7, 2020, at 1:33 AM, Benjamin Kaduk wrote: > On Thu, Feb 06, 2020 at 10:48:32AM -0800, Jeffrey Yasskin wrote: > > Sorry I'm behind on some of the other comments. > > > > On Thu, Feb 6, 2020 at 7:01 AM Benjamin Kaduk via Datatracker > > wrote: > > > > > > Benjamin Kaduk has entered the following ballot position for > > > charter-ietf-wpack-00-07: Block > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut this > > > introductory paragraph, however.) > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/charter-ietf-wpack/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > BLOCK: > > > ---------------------------------------------------------------------- > > > > > > The WPACK working group will develop a specification for a web packaging > > > format that efficiently bundles multiple HTTP representations. It will also > > > specify a way to optionally sign these resources such that a user agent can > > > trust that they came from their claimed web origins. Key goals for WPACK are: > > > > > > A key feature of the modern web is that HTTPS is becoming almost > > > universal: HTTPS provides not just encryption for the content but also > > > integrity protection and source authentication, but we've had to put a > > > fair bit of effort in to get to where we are. I'm not sure that we want > > > to leave ourselves with a new baseline of "unsigned" and another fair > > > bit of effort to get back to "most things have cryptographic > > > protection". While I recognize that there are some use cases for WPACK > > > where the origin may not be cooperative and the entity creating or > > > distributing the packages needs to remain anonymous or pseudonymous, I > > > don't think that precludes signing the resources in some way. What the > > > exact semantics of such signing would be are, of course, not clear yet, > > > but I'm reluctant to endorse a charter that describes the signing as > > > just "optional". > > > > I think it would be fine (wouldn't break any use cases) to require > > that the package be signed by *some* key, but that signature is only > > useful to a recipient if they can map it to some identity that they > > recognize. Most users don't have a public key with such an identity, > > so it didn't seem useful to require them to generate a key just to > > save a web page into a package. > > This seems like a question that should be decided by a WG and not at > charter time! > Alexeys suggestion of "a way for publishers to sign these resources" (or > perhaps even just "a way to sign these resources"?) is probably a good way > forward. I use the former. > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > * The ability to create an unsigned snapshot of a web page without the > > > cooperation of its publisher. > > > > > > Similarly, perhaps this would be "without a signature from its > > > publisher". > > > > That sounds fine to me. > > > > > * Being extensible and crypto agile. > > > > > > Generally good things, though I'm curious if there's a particular > > > direction(s) of extensibility in mind. > > > > I was thinking primarily of dealing with algorithms that get broken, > > and that's one motivation for allowing multiple signatures on a > > resource. For example, we know that post-quantum crypto is coming, and > > during the migration to it a signer might want to provide signatures > > with both an elliptic curve algorithm and a post-quantum algorithm, to > > be compatible with more clients. > > Sean's point is a good one, though it may still be worth mentioning > extensibility in its own right. I kept this item as is. > > > * Support more-efficient signing of a single, possibly same-origin HTTP > > > resource. > > > > > > More efficient than what? > > > > A multi-resource bundle has some overhead to support the ability to > > include multiple resources. The current "signed exchange" format is a > > little smaller because it doesn't need to support more than one > > resource, and I wanted the group to be able to keep that optimization. > > I'm not certain we'll wind up wanting to keep it. > > So this could be summarized as "optimizations in encoding and processing > when only a single resource (as opposed to a collection thereof) is being > packaged"? I used your text. Best Regards, Alexey From nobody Fri Feb 7 03:57:02 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7361120813; Fri, 7 Feb 2020 03:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=fastmail.fm header.b=q5g30NOw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KtF7pfI7 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 ZoWTFfVl7MUu; Fri, 7 Feb 2020 03:56:57 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3837120639; Fri, 7 Feb 2020 03:56:56 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E150621EEB; Fri, 7 Feb 2020 06:56:55 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Fri, 07 Feb 2020 06:56:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=a7nK3ImDZSQwZL+xwuehVLKml7Rr8sJ H8B1vCTvc1Hg=; b=q5g30NOwl2JbpSqmszeoecawi0n/of7aKMnD2oyBHpsaghf HZkqMfRX7u3htYIVRM1NP8iR7xA/ugkQhRTAx1Pe+8tGpIg2GZK9WH5GlQenwh79 NBc5yCGiVA48Cy05qGbugFupEFFip/R5B45xkVIshRz82FkA5cGOmdqElErZ+rB0 W9LUChbmp89U4m0aD5qWON/ttIY3VmR/AWK1k/aqRhHu0X+qb6OQ5JyaDgQ3/MtV Ab1w+AD1d/5sQ8iPTnjyo+7/BH4VjF+TxHmA9qj+bPs2nCLUY8wUny/8Opo7ehjY 6ZGm7pbWZzzFgO9YeZRa9BwrAmTQz8Ow5dt6dwQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=a7nK3I mDZSQwZL+xwuehVLKml7Rr8sJH8B1vCTvc1Hg=; b=KtF7pfI7iYUFeXlUi5F0Uv Od7Gutt2+oCnZ82XILSnowK93MWNVdHMiFqvDw31RuTBOmtHmMBO8cMO71C9tAkY 1KL63FU9bx4unEhuDmA4gefj1mfZ987HQrQgcToWoNg+WauLELwrx33YtEf5tyHL olEuUzcq6DX0XfVMqDG46V/yfpTe4Hn2EcNBPuD0qmeAjKysxZmiLPabjb/a8qSt 1CllWbGPYFHdw/+2+NDvADYe5K93R14gAZr/EKKneItNzoUjkIVumotOOi8D5n4o ojbTFwWoDWUGpViW9CBrzfesYWmCTBU3TUc95F4igr7+bw1GXmua8UrXpbCgqo/A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheehgdefgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8200A660065; Fri, 7 Feb 2020 06:56:55 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <158079132198.28494.4442064153308104629.idtracker@ietfa.amsl.com> References: <158079132198.28494.4442064153308104629.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2020 11:56:17 +0000 From: "Alexey Melnikov" To: "Adam Roach" , "The IESG" Cc: wpack@ietf.org, wpack-chairs@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] =?utf-8?q?Adam_Roach=27s_No_Objection_on_charter-ietf-wp?= =?utf-8?q?ack-00-04=3A_=28with_COMMENT=29?= 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, 07 Feb 2020 11:56:59 -0000 Hi Adam, Just to close the loop on your comments: On Tue, Feb 4, 2020, at 4:42 AM, Adam Roach via Datatracker wrote: > Adam Roach has entered the following ballot position for > charter-ietf-wpack-00-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-wpack/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > No objection to external review, but I think there are some issues we need to > see addressed prior to approval. > > > > * A low likelihood that the new format increases centralization or power > > imbalances on the web. > > I'm glad to see this in the charter. I would really like to see this bullet > point expanded to more clearly cover the three different categories of > specific concerns described in section 4.1 of draft-iab-escape-report (or, > alternately, cite that document for further detail). I think there were more comments that as stated this is not actionable, so I removed it. Jeffrey also replied to Alissa on the same issue. > > Note that consensus is required both for changes to the current protocol > > mechanisms and retention of current mechanisms > > I think this presumes a bit too much. Although the adoption of the initial > candidate documents may be highly likely, this text clearly implies that > their adoption is a fait accompli. This was edited based on suggestion from Barry. > > In particular, because > > something is in the initial document set (consisting of > > draft-yasskin-wpack-use-cases, draft-yasskin-wpack-bundled-exchanges, and > > draft-yasskin-http-origin-signed-responses) > > I also think we really need clearly-defined milestones here. Particularly, > seeing draft-yasskin-wpack-use-cases in the list of candidate documents, > I believe we need to clearly indicate whether the WG intends to publish > a use case document, especially in the context of the IESG statement at > https://ietf.org/about/groups/iesg/statements/support-documents/ > If the intention *is* to publish the document, indicating that such > is the case (and why) will help during IESG review of such a document. I addressed this by making clear in the list of milestones that the use cases documents will be a WG that is not intended to be published as an RFC. From nobody Fri Feb 7 07:11:19 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64761208A0; Fri, 7 Feb 2020 07:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.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 CKVHdVawUC5E; Fri, 7 Feb 2020 07:11:12 -0800 (PST) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660122.outbound.protection.outlook.com [40.107.66.122]) (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 9AE9212089B; Fri, 7 Feb 2020 07:11:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B1zukYh22ba51PEpR++8r0OIPdX4SCYkIWSpP6jSKL0jZ0tJrKme3mTyI5pHsvCdVX9e6MRdP5aAqPiVoJKL0erq3jKUJyig8MeTpxFhRMTTiQnJOBU+cfib9oB1xWLcUX/VMTeJ+9m04hpHXJUrDCPmHZTwa9lCSFHDLdSyGtEnLpAyJ392oQ00n7lUTinLkJS/6SJ0NPoTMLP/tspsLhQz+4i6OI/K0rUXEsKC17cm0oUQbKTZadfu0vmM/bB3C47VHLwxKcduVxnNdVkex42W9DalMc8cHg/5jFknUTpCi3mXr2Qt6xv72B7ththFqZoFZbXAmdfoR4xED/iORA== 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=q8qZtmVdy7bqzGVyd2IUhY1yLxR5sXn1G2viOOTQf58=; b=Qera7pcFJ3zmmoAKd8oX0fquu/cppcExNs3nLO0hsAqeN7rw+Wgny4p9uWrXk1nLHnctdlJlWI1dmBCV+JUWf3mrWEjBymHim6W1Yc64B4ZqpAzC28doM3JNNc7bbuuK4/NLDR1hQkBxZkfl7nsb4atItQ6gQ/+Lqvm9asAQJGXxaw6/ejfZP18uKWC4knwU9UtZTMGGjwgc4wfxGzRzNx6WbLClpwOdYjiPnsfywzoMHgr81zhY2VymDi+4KB2EI/MTdpkQr0seEPbGvsnnx+yZMQIJo68O830xQ0aux8SatNDLP5LZDfNG/57qSzvIf+tE/xW5BVWDJH+G3SEgxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=kaloom.com; dmarc=pass action=none header.from=kaloom.com; dkim=pass header.d=kaloom.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q8qZtmVdy7bqzGVyd2IUhY1yLxR5sXn1G2viOOTQf58=; b=nsFJn6RtvEQqX1hitNl/KT4kjPRnS3WZoXm/eGfwJMahc//eZRp/8xYBl3xc/YkpxYASj/lBEOfLxk0HB/PH5UBPvlA+NYI8MILcUKacFkS81mtPnxctTYlDantqwKJV8OLXRW+iWdpiBc7o3EQXpkiKz/RL3E2hdYdlcqLjQ2k= Received: from YTXPR0101MB1615.CANPRD01.PROD.OUTLOOK.COM (52.132.33.14) by YTXPR0101MB1679.CANPRD01.PROD.OUTLOOK.COM (52.132.38.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Fri, 7 Feb 2020 15:11:10 +0000 Received: from YTXPR0101MB1615.CANPRD01.PROD.OUTLOOK.COM ([fe80::90ee:fc62:858:74c7]) by YTXPR0101MB1615.CANPRD01.PROD.OUTLOOK.COM ([fe80::90ee:fc62:858:74c7%6]) with mapi id 15.20.2686.036; Fri, 7 Feb 2020 15:11:10 +0000 From: Suresh Krishnan To: Alexey Melnikov CC: The IESG , "wpack@ietf.org" , "wpack-chairs@ietf.org" Thread-Topic: Suresh Krishnan's No Objection on charter-ietf-wpack-00-07: (with COMMENT) Thread-Index: AQHV3Rxl74reqbknoU2awxQKBxPRpagP126A Date: Fri, 7 Feb 2020 15:11:09 +0000 Message-ID: References: <158096778274.30460.17533714971397286479.idtracker@ietfa.amsl.com> 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=Suresh@kaloom.com; x-originating-ip: [45.19.110.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 646373c4-e912-49dd-b056-08d7abdff6a8 x-ms-traffictypediagnostic: YTXPR0101MB1679: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0306EE2ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(136003)(396003)(346002)(376002)(366004)(199004)(189003)(5660300002)(86362001)(6512007)(508600001)(4326008)(71200400001)(6506007)(2906002)(53546011)(6486002)(4744005)(66946007)(54906003)(26005)(316002)(8676002)(33656002)(66476007)(64756008)(66556008)(66446008)(186003)(81156014)(2616005)(8936002)(6916009)(36756003)(91956017)(76116006)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:YTXPR0101MB1679; H:YTXPR0101MB1615.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gdav2+My0KsOBrYOg4gNKhKgp6jC3aR/DSmYXCncvlEsqCHLdbdZTwQCUHpSFoUzjOMa2WUtUcP9lTVw/moi/17GlonCINp1cTv0mcRaRXWP12w38Avw6cuC2O/yYmysDhqR8hT12oY+NQBvZ2/V4rOSEalGWO1WRyyzfis9N1oq9Ist8CybPk5Fb7RTZbVjwk9SbGsE4KWCdzCykHtni9pQjjTyNEovUke9218jNdcsZU6+2Sv5H8rvj7flUY1p1AFmopDcsS8gnaov87y2tN6geasMLzh9PXFwNy1ShNFL2adWOcyV6rU50oYM6LetahBhP81/x6EiyaWaJdJNUTX2mKnVTu0HlWgZDvPqUOFAeQe5WWuwRvoyyxr2IvhXlh+zsJbbtCUGwT93Qap1zIxR3/NNxFJW3UMnGADQ7KiGIDHK0t1bS4BBwDdOTYWf x-ms-exchange-antispam-messagedata: O3sHIryo7oAM9WHMWTVsnX9KGY9hcH2wCqe/hyKH3Z/kJJbul93MWxGe0idvUuC1xK1V7qdOd6ptsXZhd+59ifrk9WumsNSSU4aMTiVBeRZOoQgQ1T5lIVlET5GrY3iHRZ5DaV8C2F1wQym/NXP9eQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <03E1362E54099B44BE49E09ABCE29455@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: 646373c4-e912-49dd-b056-08d7abdff6a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2020 15:11:10.0177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: n8GLXbufvxQ/6+KVkoLOQHp4kSR8FDTHRwKa+x6Lj+MoFa/oFuq9FOwUcTjX4HZH58wF20uBs5v/ZRj+zg+jkQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB1679 Archived-At: Subject: Re: [Wpack] Suresh Krishnan's No Objection on charter-ietf-wpack-00-07: (with COMMENT) 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, 07 Feb 2020 15:11:15 -0000 > On Feb 6, 2020, at 1:36 PM, Alexey Melnikov wrot= e: >=20 > Hi Suresh, >=20 > On Thu, Feb 6, 2020, at 5:43 AM, Suresh Krishnan via Datatracker wrote: >> Suresh Krishnan has entered the following ballot position for >> charter-ietf-wpack-00-07: No Objection >> This item seems oddly specific >>=20 >> "* Allow the format to be used in self-extracting executables." >>=20 >> but it is not clear to me that this is a property of the format. Can you >> clarify a bit what the format needs to do to meet this? >=20 > I deleted it, I don't think this helps in the charter. >=20 >> Like Adam, Alissa, and Barry I would love to see a bit more elucidation = of the >> "avoid centralization" aspect of the charter. >=20 > I deleted this as well, as it read more like motherhood and apple pie. Thanks a lot Alexey!! That works out great. Regards Suresh From nobody Fri Feb 7 10:53:55 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B6E1200D5; Fri, 7 Feb 2020 10:53:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Cc: wpack@ietf.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <158110163053.11714.4626611061480809221.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2020 10:53:50 -0800 Archived-At: Subject: [Wpack] WG Review: Web Packaging (wpack) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 18:53:51 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-02-17. Web Packaging (wpack) ----------------------------------------------------------------------- Current status: BOF WG Chairs: Sean Turner Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Adam Roach Alexey Melnikov Barry Leiba Mailing list: Address: wpack@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/wpack Archive: https://mailarchive.ietf.org/arch/browse/wpack/ Group page: https://datatracker.ietf.org/group/wpack/ Charter: https://datatracker.ietf.org/doc/charter-ietf-wpack/ The WPACK working group will develop a specification for a web packaging format that efficiently bundles multiple HTTP representations. It will also specify a way for the publisher to sign these resources such that a user agent can trust that they came from their claimed web origins. Key goals for WPACK are: * Efficient storage across a range of resource combinations. Three use cases to be supported are: a client-generated snapshot of a complete web page, a web page's tree of JavaScript modules, and a selection of the whole web for peer-to-peer distribution in a country when access to authoritative servers is unavailable. * The ability to create a snapshot of a web page without the cooperation of its publisher. * The ability to use a web app online or offline, with assurance of its publisher, after a package of it was received from a peer. * Low latency to load a subresource from a package, whether the package is signed or unsigned, and whether the package is streamed or loaded from random-access storage. * Being extensible and crypto agile. * Security and privacy properties of using signed bundles as close as practical to TLS 1.3 transport of the same resources. Where properties do change, the group will document exactly what changed and how affected people, including content publishers and users, can compensate. Part of this is analyzing how the shift from transport security to object security changes the security properties of the web's existing features. * Specifying constraints on how clients load the formats without describing specific loading algorithm to help achieve the above goals. The packaging format will also aim to achieve the following secondary goals as long as they don't compromise or delay the above properties. * Optimizations in encoding and processing when only a single resource (as opposed to a collection thereof) is being packaged * Support signed statements about subresources beyond just assertions that they're accurate representations of particular URLs. * Address the threat model of a website compromised after a user first uses the site. * Support books being published in the format. * Optimize transport of large numbers of small same-origin resources. * Allow publishers to efficiently combine sub-packages from other publishers. The following goals are out of scope under this charter: * DRM (Digital Rights Management) * A way to distribute the private portions of a website. For example, WPACK might define a way to distribute a messaging application but wouldn't define a way to distribute individual messages without a direct connection to the messaging application's origin server. * Defining the details of how web browsers load the formats and interact with any protocols we define here, aside from the constraints mentioned above. * A way to automatically discover the URL for an accessible package that includes specific content. Note that consensus is required both for changes to the initially proposed protocol mechanisms and for their retention. In particular, because something is in an initial working group draft does not imply that there is consensus around the feature or around how it is specified. Relationship to Other WGs and SDOs WPACK will work with the W3C and WHATWG to identify the existing security and privacy models for the web, and to ensure those SDOs can define how this format is used by web browsers. The WPACK working group will work closely with the HTTPbis working group, in particular WPACK will attempt to reuse HTTPBIS work on HTTP signing. Milestones: Jun 2020 - Working group adoption of use cases document (will not be published as an RFC) Jun 2020 - Working group adoption of bundling document Jun 2020 - Working group adoption of security analysis document Jun 2020 - Working group adoption of privacy analysis document Jun 2020 - Working group adoption of signing document Sep 2021 - Submit the Bundling document to IESG Mar 2022 - Submit the Privacy analysis document to IESG Mar 2022 - Submit the Security analysis document to IESG Mar 2022 - Submit the Signing document to IESG From nobody Mon Feb 17 18:46:32 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5727C12086D; Mon, 17 Feb 2020 11:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErNFPgRROefX; Mon, 17 Feb 2020 11:52:20 -0800 (PST) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1708512086C; Mon, 17 Feb 2020 11:52:20 -0800 (PST) Received: by mail-oi1-f175.google.com with SMTP id d62so17761979oia.11; Mon, 17 Feb 2020 11:52:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4G9AwtYMVeSqKC6bluKGOt/OPC6JHqmu4/uN8KcHRHY=; b=bMj8YNWIjPho0H8YosCnqwGIPY8RMb1/omjY2jEQQuVCIMQJ+e5Q5t6+HRdVSVQh4m QJ5MVHf6I8DjUuonwYBAu+eraaakxKONRvB0toI9QXBVNs4sY+rMOdV6IZwxcgeiaW9A yrDxU07hbjAQTgsxeoEJe16o3WotfIFnqrAHmgsMUREvAOK9tX1ScqzIIKIic3QNUhQN U6cX0bX8c2Yo/xjUHiiNnS4H/Kum1oYaSns5ivIXKm+hlyghs/FoSh0At0hmfPsCvk9G bmOiO7qq2H8z5fo+LndJWp99Da0TY00bmUIUB4ceNQMrm7UGsC9vQRIofGmOt0HeU3eg wHaw== X-Gm-Message-State: APjAAAX3eQI/iZ1AYaNjg4wLxUtQukWwAqjTIcGE4wdjeMzE4vW83a26 hqEcqcTMQplmogETPzNVKNi+xrWaSKQ7KXImvlo8pcGeT9o= X-Google-Smtp-Source: APXvYqy0zPaclXD+T5LW7afAnrtfgwrqCa6YjXkfmRYJolzDxNbV7+4yfhdI3ORWTxpCLcntlkbEOA2eKdvw4qr3P0c= X-Received: by 2002:aca:ccce:: with SMTP id c197mr393550oig.31.1581969138818; Mon, 17 Feb 2020 11:52:18 -0800 (PST) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Mon, 17 Feb 2020 14:52:08 -0500 Message-ID: To: The IESG , wpack@ietf.org Content-Type: multipart/alternative; boundary="00000000000090a32e059ecae4e2" Archived-At: Subject: [Wpack] WG Review: Web Packaging (wpack) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 19:52:22 -0000 --00000000000090a32e059ecae4e2 Content-Type: text/plain; charset="UTF-8" I am a bit fuzzy on the non requirements. In particular, the DRM non requirement. If you have a means to publish a compound document as a book and you have a means to protect the privacy of that compound document, you have the ability to encrypt which means that you have a certain level of DRM capability. As I see it DRM is a combination of two problems, one control over initial distribution, the second control over redistribution. The second has proved to be infeasible of course but the first is quite tractable. So I think it would be useful to narrow the statement to controlling redistribution. What I think is also intended here is that the group does not consider the protocol(s) by which access tokens are exchanged beyond the simplest case of passing a key over a TLS connection. This should probably be stated directly. Also, I think that rather than a 'signing document', the group really has a syntax document and it is far from clear that there will be only one. My work requires a blockchain type capability, that is incremental authentication and encryption. I certainly plan to re-use the bundling semantics but I can't make use of a syntax that arbitrarily dismisses my core requirements. --00000000000090a32e059ecae4e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= m a bit fuzzy on the non requirements. In particular, the DRM non requireme= nt.

<= div class=3D"gmail_default" style=3D"font-size:small">If you have a means t= o publish a compound document as a book and you have a means to protect the= privacy of that compound document, you have=C2=A0the ability to encrypt wh= ich means that you have a certain level of DRM capability.

As I see it DRM is a combination of two = problems, one control over initial distribution, the second control over re= distribution. The second has proved to be infeasible of course but the firs= t is quite tractable. So I think it would be useful to narrow the=C2=A0stat= ement to controlling redistribution.


What=C2=A0I think is also intended here is that the group does not consid= er the protocol(s) by which access tokens are exchanged beyond the simplest= case of passing a key over a TLS connection. This should probably be state= d directly.=C2=A0

Also, I= think that rather than a 'signing document', the group really=C2= =A0has a syntax document and it is far from clear that there will be only o= ne. My work requires a blockchain type capability, that is incremental auth= entication and encryption. I certainly plan to re-use the bundling semantic= s but I can't make use of a syntax that arbitrarily dismisses my core r= equirements.
--00000000000090a32e059ecae4e2-- From nobody Wed Feb 19 21:15:00 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC907120143; Wed, 19 Feb 2020 21:14:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: wpack-chairs@ietf.org, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158217569061.17592.11208155115949408581.idtracker@ietfa.amsl.com> Date: Wed, 19 Feb 2020 21:14:50 -0800 Archived-At: Subject: [Wpack] Alissa Cooper's No Record on charter-ietf-wpack-00-09: (with COMMENT) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 05:14:51 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-wpack-00-09: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-wpack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Ben that the comments received just before and after the last telechat should be discussed on the mailing list before we approve this. From nobody Thu Feb 20 02:14:36 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B663120251; Thu, 20 Feb 2020 02:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=fastmail.fm header.b=fDzOQGHZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3KD/uX08 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 P7UL-vlCJzs4; Thu, 20 Feb 2020 02:14:25 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B9A1200E6; Thu, 20 Feb 2020 02:14:25 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AA1FA21B0E; Thu, 20 Feb 2020 05:14:24 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Thu, 20 Feb 2020 05:14:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=21R2OnAzAC2ayOkoO8C5dRbXsaaot8K Va98h8poVfbU=; b=fDzOQGHZnB4RefggYDo7/K9Rpx589hfFM5h8jBc34WBRBB2 NJ/VtAlff1K/RX3aOsZGC/fy39eImi4dA1vcctqiVeKS0ZSCeElV0KIcmKgcy0qM 91pC5MIDKcMitxSO88YnfnhSLO6+LW0QMAixYjuJT0nZYL4VlMH+ibeZ1DwgLr5e BBl87gRQLeEEVbtpI94facHVQXphIKsw8iiUmg6YNSky0YeLC/zDmoSvlhAXYisX cBMS8Y8TdMxmPIA7aCi4KCNAqkiabQj+/mAcQGx2gPiQHifRq5Q0/4hLjO7uwCfX lh9Fig2opQUFgpuShZqn+4+ludVdCMnBrG9ZDPA== 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=fm2; bh=21R2On AzAC2ayOkoO8C5dRbXsaaot8KVa98h8poVfbU=; b=3KD/uX08SUozdcr/ZIXwkF MsZhkvD6JtuzbZvjFxsR7M+X4S4r7aR0bSOIz6X30UxdyTZrj1ISGuYoYLUBporx AopyppAQaNuwCKoRqW4a153h/UMpdauUSfSwZy+3okc28bCSUPf4jSporpjMOjsB P2FksxwW4ZLkYBun2HYhTAGRO+XYNxxTjKMpgK5/jOhcNQBxncKFnquFaoG88ckg qrQ9Gao++61nCz+HtRNBzgjXPTYL8harPMHsFc5CFiBmC12VnFeQYoxlnD+sKqqW sPK1W3Vj/iwE23W2JBu+SoCu2ftNKpDQZ3bfgQ4t3WtmeQ/HIG81hsSBLUFY7vEg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkedvgddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr rghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 28ED0660065; Thu, 20 Feb 2020 05:14:24 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <67f0b1e8-429c-42e8-b2cd-ed3d871532ab@www.fastmail.com> In-Reply-To: References: Date: Thu, 20 Feb 2020 10:14:03 +0000 From: "Alexey Melnikov" To: "Phillip Hallam-Baker" , "The IESG" , wpack@ietf.org Content-Type: multipart/alternative; boundary=83131e585b8b43e0a9c6df3671c90df1 Archived-At: Subject: Re: [Wpack] WG Review: Web Packaging (wpack) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 10:14:28 -0000 --83131e585b8b43e0a9c6df3671c90df1 Content-Type: text/plain Hi Phillip, Thank you for your comments. My answers below. On Mon, Feb 17, 2020, at 7:52 PM, Phillip Hallam-Baker wrote: > I am a bit fuzzy on the non requirements. In particular, the DRM non requirement. > > If you have a means to publish a compound document as a book and you have a means to protect the privacy of that compound document, you have the ability to encrypt which means that you have a certain level of DRM capability. > > As I see it DRM is a combination of two problems, one control over initial distribution, the second control over redistribution. The second has proved to be infeasible of course but the first is quite tractable. So I think it would be useful to narrow the statement to controlling redistribution. I think the idea is to declare both out of scope, so I would rather not get into details of how DRM might be implemented using the format. So I suggest no change. > What I think is also intended here is that the group does not consider the protocol(s) by which access tokens are exchanged beyond the simplest case of passing a key over a TLS connection. This should probably be stated directly. I am not entirely clear where this text can be inserted. Can you suggest some specific text and where to insert it > Also, I think that rather than a 'signing document', the group really has a syntax document and it is far from clear that there will be only one. My work requires a blockchain type capability, that is incremental authentication and encryption. I certainly plan to re-use the bundling semantics but I can't make use of a syntax that arbitrarily dismisses my core requirements. There is no mentioning of "signing document" in the charter. I think what you propose is a very reasonable thing to discuss in the WG when it is formed. Best Regards, Alexey --83131e585b8b43e0a9c6df3671c90df1 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Phillip= ,
Thank you for your comments. My answers below.

On Mon, Feb 17, 2020, at 7:52 PM, Phillip Hallam-Baker w= rote:
I am a bit fuzzy = on the non requirements. In particular, the DRM non requirement.

<= div style=3D"font-size:small;" class=3D"qt-gmail_default">If you have a = means to publish a compound document as a book and you have a means to p= rotect the privacy of that compound document, you have the ability = to encrypt which means that you have a certain level of DRM capability.<= br>

=
As I se= e it DRM is a combination of two problems, one control over initial dist= ribution, the second control over redistribution. The second has proved = to be infeasible of course but the first is quite tractable. So I think = it would be useful to narrow the statement to controlling redistrib= ution.
I think the idea is to declare b= oth out of scope, so I would rather not get into details of how DRM migh= t be implemented using the format. So I suggest no change.

What I think is = also intended here is that the group does not consider the protocol(s) b= y which access tokens are exchanged beyond the simplest case of passing = a key over a TLS connection. This should probably be stated directly.&nb= sp;
I am not entirely clear where this = text can be inserted. Can you suggest some specific text and where to in= sert it


Also, I think that rather than a 'signing document', the group = really has a syntax document and it is far from clear that there wi= ll be only one. My work requires a blockchain type capability, that is i= ncremental authentication and encryption. I certainly plan to re-use the= bundling semantics but I can't make use of a syntax that arbitrarily di= smisses my core requirements.

There is no mentioning of "signing document" in the charter. I thi= nk what you propose is a very reasonable thing to discuss in the WG when= it is formed.

Best Regards,
= Alexey
--83131e585b8b43e0a9c6df3671c90df1-- From nobody Thu Feb 20 02:22:54 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EB2120096; Thu, 20 Feb 2020 02:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=fastmail.fm header.b=d/mphmyg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=H83eZwj9 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 yUtJ2oiA9B-F; Thu, 20 Feb 2020 02:22:43 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E802C12001A; Thu, 20 Feb 2020 02:22:42 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2736F21DC6; Thu, 20 Feb 2020 05:22:42 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Thu, 20 Feb 2020 05:22:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=1BhUVagBeH2jYjq0jztYE47GHjJxEyJ 6+TEMc8PIC9s=; b=d/mphmygtJTWThbEFZfpyp0gMoPr6Yz2tb79MAK/wxpXYJJ E3LDpEnsQS6sq0B2s7OQlzX2GFCynUy3Qu7kX7SPlZI0UIZuADeIN7qm3uAjvhw+ gOorWNviKx8gynTHMUUw7/pM2ANdgUBE5B4hLkhPwrH6FxS1ZCSpYKRXGUiFW6yU luiavU/TuwWXp+CIVo79DHPMPrCFeRUX0cLZsiSqioa5FAvCSqEJb+Yn570nWZdE N4NY48KIfz091J6w7645KMK9K1OOc/8OuowC3pm+0vi4UXg07wqVGwz5IN0d9lB1 4DhieSLN+WHUqa9Oww8VpYAzskuCtt1CkPp32Wg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=1BhUVa gBeH2jYjq0jztYE47GHjJxEyJ6+TEMc8PIC9s=; b=H83eZwj9wERfSy9bYHRpTa kvhTZspabdnp/8F1tKIXxO6jxTwkw/5oHkM0HRRkYX+tJeCF6lF7fjid9hMjl1Fq LvvxHk2pTVyL9/bb9iAY+tnm8si/UtMBYf4j3czWN2/rGqEEL0Pj70LSZlGyC4xY FakzotfAFaBuyxSx4OckU0xFTf+pJjjKlllYOHnLFEJJ1zJCEEqHWJEMrQiKGoXg QNw7SxYR9gWvooyi/WnpVUpP47jZ/5HzJJyAeZZJL2AYDzL/doyr2RGqxiCSPQCz n9RGRblzu0i/IF2GKkm1efQmZOst2lMM51gieVqwhRuJM3rmEJfTpCva/t99bWLQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkedvgdduiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghl nhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdr fhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E9667660065; Thu, 20 Feb 2020 05:22:41 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <7e8eeec9-cda6-4fab-9065-7a179ec64afb@www.fastmail.com> In-Reply-To: <007b01d5dd24$127e5cd0$377b1670$@acm.org> References: <007b01d5dd24$127e5cd0$377b1670$@acm.org> Date: Thu, 20 Feb 2020 10:22:08 +0000 From: "Alexey Melnikov" To: "Larry Masinter" , iesg@ietf.org Cc: wpack@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] wpack charter X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 10:22:46 -0000 Hi Larry, Thank you for your comments. On Thu, Feb 6, 2020, at 7:31 PM, Larry Masinter wrote: > > Actually the list of goals seems to list a quite large variety of > different aspects on various levels of depth. > > It not clear to me if all this needs to be in the charter. If there is > agreement about what the group wants > > to do that good of course but (as the one mentioned above) if it's not > clear how a goal would actually impact > > the technical work/format, it not fully clear to me why it is listed in > the charter. Yes. On closer examination it became apparent that some requirements are not really actionable. Hopefully I removed all of them. > > Perhaps some guidelines on charter-writing would be useful? > > The purpose of a charter is to establish scope (as an upper bound) and > success (as a lower bound)., as > well as starting points. > > But most of the requirements in charter-ietf-wpack are goals which are not > orthogonal and can be > In conflict. And "Efficient" "agile" "as close as practical" and the like > don't seem to either establish scope or success > criteria, but are design metrics but will need to be traded off. > > I'd suggest taking the "Key goals for WPACK are" and "the following goals > are out of scope" > Putting them in an Internet Draft (or combine them with the use cases > document). I think this is sort of what already happened, but it would be hard to check whether Charter goals are achieved if it just references a document that can mutate over time. The current charter text is by no means perfect, but it is the best attempt to list some specific goals. > Personally, I don't see the reason not to publish the use cases and goals as > an RFC with an early milestone. > I think you'll get better review to spend the time to do the work to > evaluate the goals across use cases. > > The charter mentions several documents that are not listed with URLs Other reviewers complained that listing specific drafts presupposes specific outcome, so I took them out! Best Regards, Alexey From nobody Thu Feb 20 05:11:13 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCC81200F9; Thu, 20 Feb 2020 05:11:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: wpack-chairs@ietf.org, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <158220427150.12424.6173475152192439782.idtracker@ietfa.amsl.com> Date: Thu, 20 Feb 2020 05:11:11 -0800 Archived-At: Subject: [Wpack] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Record_on_charter-?= =?utf-8?q?ietf-wpack-00-11=3A_=28with_COMMENT=29?= X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 13:11:12 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-wpack-00-11: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-wpack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Waiting for an update before I ballot... From nobody Fri Feb 21 09:23:50 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD701200CC; Fri, 21 Feb 2020 09:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lK6nIAYIa6g; Fri, 21 Feb 2020 09:23:46 -0800 (PST) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (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 32387120147; Fri, 21 Feb 2020 09:23:46 -0800 (PST) Received: by mail-ot1-f45.google.com with SMTP id r27so2658468otc.8; Fri, 21 Feb 2020 09:23:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nuZtWC0bw2tysMuiPWjfotlCglaElFu5djYDYEL3NJc=; b=RET49oQsbH/8sgWKaOt2pz/Qe+COx0FxWN3NEZyxePe55CJ3JQpB3K9pEkDUlMc372 dG6FiLM/ulfjLgW32hwl5zLck1vmWhb3QrmJT6kohl88s6md1CckeScvjEy2BYNK/fem QAM2k1e9+PwNNbRLDVvzirXcBHcGFUnIXVhembzNFVKV/704ZqGOKbmFU+hKXL5Ubv8B z3tqVKIvpioN6DrY+uO1+Tef0QGD3NSXO4EMDp5VJCpIz1ee84g7xpcc/IaLRr6hXHJp +3M5IiA5451OPklh2ANVIBIeIDWvzx8qxIAa9f4UX0nDYkhg7LOaWm3XTVl2sr3aWvyS uKhA== X-Gm-Message-State: APjAAAV6MoGFQaUrQfTjg8cOd0w02TqNb+LpY6TVplVh19Xvsac1K0yi 5gch35ZK0PBkblmcd1jUMLSFglKkck0Dty077Mg= X-Google-Smtp-Source: APXvYqw+dm93N+x0PuFVxduPcYDW1NNoLM88ZRGgiAFzYcxt/nFej+snWjWkKHclmMdlMgt3P6c+VywjOCrcbU9YESw= X-Received: by 2002:a05:6830:1305:: with SMTP id p5mr27102755otq.124.1582305825320; Fri, 21 Feb 2020 09:23:45 -0800 (PST) MIME-Version: 1.0 References: <67f0b1e8-429c-42e8-b2cd-ed3d871532ab@www.fastmail.com> In-Reply-To: <67f0b1e8-429c-42e8-b2cd-ed3d871532ab@www.fastmail.com> From: Phillip Hallam-Baker Date: Fri, 21 Feb 2020 12:23:34 -0500 Message-ID: To: Alexey Melnikov Cc: The IESG , wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000a4f2b2059f19484e" Archived-At: Subject: Re: [Wpack] WG Review: Web Packaging (wpack) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 17:23:48 -0000 --000000000000a4f2b2059f19484e Content-Type: text/plain; charset="UTF-8" The signing doc is mentioned in the milestones: Milestones: Jun 2020 - Working group adoption of use cases document (will not be published as an RFC) Jun 2020 - Working group adoption of bundling document Jun 2020 - Working group adoption of security analysis document Jun 2020 - Working group adoption of privacy analysis document Jun 2020 - Working group adoption of signing document Sep 2021 - Submit the Bundling document to IESG Mar 2022 - Submit the Privacy analysis document to IESG Mar 2022 - Submit the Security analysis document to IESG Mar 2022 - Submit the Signing document to IESG I can't focus enough for wordsmithing at the moment. So I'll withdraw my other points. Having spent a couple of years playing with this space I think that it is actually quite constrained at a certain level that is a bit more abstract than syntax but still involving the order in which information is presented. If you write out all the maximal requirements, there is only really one way to do it that makes sense. The only thing that is innovative in my work (DARE) is the way I provide for incremental encryption and the profiling I do on JOSE to provide RAILS like fluency. On Thu, Feb 20, 2020 at 5:14 AM Alexey Melnikov wrote: > Hi Phillip, > Thank you for your comments. My answers below. > > On Mon, Feb 17, 2020, at 7:52 PM, Phillip Hallam-Baker wrote: > > I am a bit fuzzy on the non requirements. In particular, the DRM non > requirement. > > If you have a means to publish a compound document as a book and you have > a means to protect the privacy of that compound document, you have the > ability to encrypt which means that you have a certain level of DRM > capability. > > As I see it DRM is a combination of two problems, one control over initial > distribution, the second control over redistribution. The second has proved > to be infeasible of course but the first is quite tractable. So I think it > would be useful to narrow the statement to controlling redistribution. > > I think the idea is to declare both out of scope, so I would rather not > get into details of how DRM might be implemented using the format. So I > suggest no change. > > What I think is also intended here is that the group does not consider the > protocol(s) by which access tokens are exchanged beyond the simplest case > of passing a key over a TLS connection. This should probably be stated > directly. > > I am not entirely clear where this text can be inserted. Can you suggest > some specific text and where to insert it > > > Also, I think that rather than a 'signing document', the group really has > a syntax document and it is far from clear that there will be only one. My > work requires a blockchain type capability, that is incremental > authentication and encryption. I certainly plan to re-use the bundling > semantics but I can't make use of a syntax that arbitrarily dismisses my > core requirements. > > > There is no mentioning of "signing document" in the charter. I think what > you propose is a very reasonable thing to discuss in the WG when it is > formed. > > Best Regards, > Alexey > --000000000000a4f2b2059f19484e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The signing doc is mentioned in the milestones:

Milestones:

=C2=A0 Jun 2020 - W= orking group adoption of use cases document (will not be
=C2=A0 publishe= d as an RFC)

=C2=A0 Jun 2020 - Working group adoption of bundling do= cument

=C2=A0 Jun 2020 - Working group adoption of security analysis= document

=C2=A0 Jun 2020 - Working group adoption of privacy analys= is document

=C2=A0 Jun 2020 - Working group adoption of signing docu= ment

=C2=A0 Sep 2021 - Submit the Bundling document to IESG

= =C2=A0 Mar 2022 - Submit the Privacy analysis document to IESG

=C2= =A0 Mar 2022 - Submit the Security analysis document to IESG

=C2=A0 = Mar 2022 - Submit the Signing document to IESG


I can't focus enough for wordsmithing at the moment. So I'll with= draw my other points.=C2=A0

Having spent a couple of years playing with this space I think that it i= s actually quite constrained at a certain level that is a bit more abstract= than syntax but still involving the order in which information is presente= d. If you write out all the maximal requirements, there is only really one = way to do it that makes sense.

The only thing that is innovative in my work (DARE) is the way I prov= ide for incremental encryption and the profiling I do on JOSE to provide RA= ILS like fluency.


On Thu, Feb 20, 2020 at 5:14 AM Alexey Melnikov = <aamelnikov@fastmail.fm>= ; wrote:
=
Hi=C2=A0Phillip,
Thank you for your comments. My an= swers below.

On Mon, Feb 17, 2020, at 7:52 PM, Phi= llip Hallam-Baker wrote:
I am= a bit fuzzy on the non requirements. In particular, the DRM non requiremen= t.

If you have a means to publish a compound document as a book and y= ou have a means to protect the privacy of that compound document, you have= =C2=A0the ability to encrypt which means that you have a certain level of D= RM capability.

As I see it DRM is a combination of two problems, one = control over initial distribution, the second control over redistribution. = The second has proved to be infeasible of course but the first is quite tra= ctable. So I think it would be useful to narrow the=C2=A0statement to contr= olling redistribution.
I think the idea is= to declare both out of scope, so I would rather not get into details of ho= w DRM might be implemented using the format. So I suggest no change.

What=C2=A0I think is= also intended here is that the group does not consider the protocol(s) by = which access tokens are exchanged beyond the simplest case of passing a key= over a TLS connection. This should probably be stated directly.=C2=A0
<= /div>
I am not entirely clear where this text can be= inserted. Can you suggest some specific text and where to insert it
<= div>

Also, I t= hink that rather than a 'signing document', the group really=C2=A0h= as a syntax document and it is far from clear that there will be only one. = My work requires a blockchain type capability, that is incremental authenti= cation and encryption. I certainly plan to re-use the bundling semantics bu= t I can't make use of a syntax that arbitrarily dismisses my core requi= rements.

There is no mentio= ning of "signing document" in the charter. I think what you propo= se is a very reasonable thing to discuss in the WG when it is formed.

Best Regards,
Alexey
--000000000000a4f2b2059f19484e-- From nobody Fri Feb 21 09:27:50 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0136012023E; Fri, 21 Feb 2020 09:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Oildvq5q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SUN6M3mY 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 V4CVRNIl4C9R; Fri, 21 Feb 2020 09:27:37 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C992120147; Fri, 21 Feb 2020 09:27:37 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 339D622027; Fri, 21 Feb 2020 12:27:36 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Fri, 21 Feb 2020 12:27:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=y2wwHB5RrF+F3jBKFLSW0mvP1fjN+8z LqGUBhc4LQF8=; b=Oildvq5qs3AHV7BNHbSmeQZ/+/yaFcY1ceUlHLb/S8Ov3oK WXQWqpJ9Tsh4mVNp+2F2EqRIhUCHfM8n5vwXeYTEQDcno2SLkyFcfRtMrkYEhujG TX1hLKSLAliB5+HBQJJ+bU/WgJAEQjlnIkTbhq9IUdmD/Sg6mmtdgD3UH8g4Ko+3 uPUXyVHat4E3OliV7EhwvVdgvyMA/0f9DeOP1OtJMXoL7B533uuKI6tUu6iGJTjP G/YFPTgdPyYvE/tHGq24ONFx2tBEjLcUr+MxR6vzmZ2ckj+XlG8k9nhCWY1y5LsW kizdfdmt2lYm0VyPm7QA57z/P3hJQ1AByDDwbzw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=y2wwHB 5RrF+F3jBKFLSW0mvP1fjN+8zLqGUBhc4LQF8=; b=SUN6M3mYLmGnp6yH+5VN34 +TUryux/X/ZVIr3zFa97wVsBc2DXLviFOZcoECezbiOBojCR/8D6q2OjqQk/bbDT 1Ubc6jmbqRal3YeoNSrn1mkR1t9JzMWRRlCi9UyQfKwJeixbrb8uHvktsMFth0HZ mAo9BUzvwsIkpA1ntaCvR9VB/Px6s7VcP3MOyPE+BZLvCALkwlcZyS0LPKnWf5q/ k6lomxT0Tu/h2FicWJsaeLg6TIyETZ7bkpNGg78eSSPukXkjNlQouj+thcJaI3VJ R5OelxYPR5WltCGYAZX/qDSFonQrseKDrEXzeBcX9J828365G6gHs2Od32euL4rg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeeggddutdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6AC81660069; Fri, 21 Feb 2020 12:27:35 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <43bce917-e303-47bb-bc82-4c47cc42ac7a@www.fastmail.com> In-Reply-To: References: <67f0b1e8-429c-42e8-b2cd-ed3d871532ab@www.fastmail.com> Date: Fri, 21 Feb 2020 17:26:56 +0000 From: "Alexey Melnikov" To: "Phillip Hallam-Baker" Cc: "The IESG" , wpack@ietf.org Content-Type: multipart/alternative; boundary=ca8f6115fd3b42739ac1be99e1200f9d Archived-At: Subject: Re: [Wpack] WG Review: Web Packaging (wpack) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 17:27:40 -0000 --ca8f6115fd3b42739ac1be99e1200f9d Content-Type: text/plain Hi Phillip, On Fri, Feb 21, 2020, at 5:23 PM, Phillip Hallam-Baker wrote: > The signing doc is mentioned in the milestones: > > Milestones: > > Jun 2020 - Working group adoption of use cases document (will not be > published as an RFC) > > Jun 2020 - Working group adoption of bundling document > > Jun 2020 - Working group adoption of security analysis document > > Jun 2020 - Working group adoption of privacy analysis document > > Jun 2020 - Working group adoption of signing document Oh, I see. Yes, I think changing it to "syntax document" is reasonable. Best Regards, Alexey > > Sep 2021 - Submit the Bundling document to IESG > > Mar 2022 - Submit the Privacy analysis document to IESG > > Mar 2022 - Submit the Security analysis document to IESG > > Mar 2022 - Submit the Signing document to IESG > > > I can't focus enough for wordsmithing at the moment. So I'll withdraw my other points. > > Having spent a couple of years playing with this space I think that it is actually quite constrained at a certain level that is a bit more abstract than syntax but still involving the order in which information is presented. If you write out all the maximal requirements, there is only really one way to do it that makes sense. > > The only thing that is innovative in my work (DARE) is the way I provide for incremental encryption and the profiling I do on JOSE to provide RAILS like fluency. > > > On Thu, Feb 20, 2020 at 5:14 AM Alexey Melnikov wrote: >> __ >> Hi Phillip, >> Thank you for your comments. My answers below. >> >> On Mon, Feb 17, 2020, at 7:52 PM, Phillip Hallam-Baker wrote: >>> I am a bit fuzzy on the non requirements. In particular, the DRM non requirement. >>> >>> If you have a means to publish a compound document as a book and you have a means to protect the privacy of that compound document, you have the ability to encrypt which means that you have a certain level of DRM capability. >>> >>> As I see it DRM is a combination of two problems, one control over initial distribution, the second control over redistribution. The second has proved to be infeasible of course but the first is quite tractable. So I think it would be useful to narrow the statement to controlling redistribution. >> I think the idea is to declare both out of scope, so I would rather not get into details of how DRM might be implemented using the format. So I suggest no change. >> >>> What I think is also intended here is that the group does not consider the protocol(s) by which access tokens are exchanged beyond the simplest case of passing a key over a TLS connection. This should probably be stated directly. >> I am not entirely clear where this text can be inserted. Can you suggest some specific text and where to insert it >> >> >>> Also, I think that rather than a 'signing document', the group really has a syntax document and it is far from clear that there will be only one. My work requires a blockchain type capability, that is incremental authentication and encryption. I certainly plan to re-use the bundling semantics but I can't make use of a syntax that arbitrarily dismisses my core requirements. >> >> There is no mentioning of "signing document" in the charter. I think what you propose is a very reasonable thing to discuss in the WG when it is formed. >> >> Best Regards, >> Alexey --ca8f6115fd3b42739ac1be99e1200f9d Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Phillip,

On Fri, Feb 21, 2020, at 5:23 PM, Phillip Hallam-B= aker wrote:
The signing doc is mentioned in the milestones:

Milestones:
=

  Jun 2020 - Working group adoption of use case= s document (will not be
  published as an RFC)

  Jun 2020 - Working group adoption of bundl= ing document

  Jun 2020 - Working grou= p adoption of security analysis document

&n= bsp; Jun 2020 - Working group adoption of privacy analysis document
<= /div>

  Jun 2020 - Working group adoption of sig= ning document

Oh, I see. Yes, I think changing it to "syntax document" is reasonable= .

Best Regards,
Alexey
<= div>
<= div>
  Sep 2021 - Submit the Bundling document to IES= G

  Mar 2022 - Submit the Privacy anal= ysis document to IESG

  Mar 2022 - Sub= mit the Security analysis document to IESG

=   Mar 2022 - Submit the Signing document to IESG


I can't focus enough for wordsmithing at the mo= ment. So I'll withdraw my other points. 

Having spent a couple of years pl= aying with this space I think that it is actually quite constrained at a= certain level that is a bit more abstract than syntax but still involvi= ng the order in which information is presented. If you write out all the= maximal requirements, there is only really one way to do it that makes = sense.

= The only thing that is innovative in my work (DARE) is the way I provide= for incremental encryption and the profiling I do on JOSE to provide RA= ILS like fluency.


On Thu, Fe= b 20, 2020 at 5:14 AM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
<= br>
Hi Phillip,
Thank you for your com= ments. My answers below.

On Mon, Feb 17, 20= 20, at 7:52 PM, Phillip Hallam-Baker wrote:
I am a bit fuzzy on the non requirements. In pa= rticular, the DRM non requirement.

If you have a means to pub= lish a compound document as a book and you have a means to protect the p= rivacy of that compound document, you have the ability to encrypt w= hich means that you have a certain level of DRM capability.

A= s I see it DRM is a combination of two problems, one control over initia= l distribution, the second control over redistribution. The second has p= roved to be infeasible of course but the first is quite tractable. So I = think it would be useful to narrow the statement to controlling red= istribution.
I think the idea is to dec= lare both out of scope, so I would rather not get into details of how DR= M might be implemented using the format. So I suggest no change.

What I= think is also intended here is that the group does not consider the pro= tocol(s) by which access tokens are exchanged beyond the simplest case o= f passing a key over a TLS connection. This should probably be stated di= rectly. 
I am not entirely clear w= here this text can be inserted. Can you suggest some specific text and w= here to insert it


Also, I think that rather than a 'signing doc= ument', the group really has a syntax document and it is far from c= lear that there will be only one. My work requires a blockchain type cap= ability, that is incremental authentication and encryption. I certainly = plan to re-use the bundling semantics but I can't make use of a syntax t= hat arbitrarily dismisses my core requirements.

There is no mentioning of "signing document" in = the charter. I think what you propose is a very reasonable thing to disc= uss in the WG when it is formed.

Best Regar= ds,
Alexey

--ca8f6115fd3b42739ac1be99e1200f9d-- From nobody Fri Feb 21 09:40:36 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBAF12013B; Fri, 21 Feb 2020 09:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=mqb128cs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YbVLIOuk 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 xYD6P4f55OJf; Fri, 21 Feb 2020 09:40:12 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D02C512083F; Fri, 21 Feb 2020 09:40:11 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C8A0B22083; Fri, 21 Feb 2020 12:40:10 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Fri, 21 Feb 2020 12:40:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=3kJyQmQS1fbfztkvtwpehK3+RSAyU6e G0/gX+6VvgyA=; b=mqb128csBSl2De+qpAYAXuQTxussMhun0AOuYKPG4Knv+g0 PVVI+GwKyH0gGCYOGvnVh4hNVveN2jYk1LKXDBIi7P4wDje6c9sXNY4nR9yfQfA9 rSkMUDTEaiSaUfTgsFSgjCxkycXHQf+PAB9TBYqgzYixCA+ImtqpclpInLFjv2dp KMyn5pdYW4Ili1d67G2kU63UK7ce5+XvbWhc77kzuv9hWXBSUMs6wHFaoGyNX1W4 J0ycXYDydS5QroNP57ct2joaCyy8OxAUXJVrFoQHQl3SbzsdaOM5Yfv6f03IMxAV tXd8XPZcbvKwYdKJxqCrBYzabVUFDvIHhb0Kdrg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=3kJyQm QS1fbfztkvtwpehK3+RSAyU6eG0/gX+6VvgyA=; b=YbVLIOuk5dxQ9g/TpHVaSx CI7XJ+jv9cA1+ea/hjarK2MbaoZgvpIA1C/BWMta6HAC4S9zj8ZxV1AoaZXpuc6L FG57zzequnHBjZg/iKYG84CjnOyI9Z5+1rxeQiaJZystJqmdh/LYWdJsMHvsg8Ok k6HY0vFwnui+htzC5vDd5+2PY3ACgLPWvS7FGofHJgNC08Oylo9gpI4dvLldrVF9 gGJgncEvOtHBVNYpMjmFsojl6kBdS00zFjKTq21we466VxFpiu+Agfnm42lt0OAG DVisR97ERdGdq1pkHqBhaJerAx/7gEFNTJYnkbC10/9Qojxd/h3a96uegcoa7L3w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeeggddutdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 88772660069; Fri, 21 Feb 2020 12:40:10 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <9a8683b6-0eee-42cc-bec9-93d7ad905647@www.fastmail.com> In-Reply-To: <43bce917-e303-47bb-bc82-4c47cc42ac7a@www.fastmail.com> References: <67f0b1e8-429c-42e8-b2cd-ed3d871532ab@www.fastmail.com> <43bce917-e303-47bb-bc82-4c47cc42ac7a@www.fastmail.com> Date: Fri, 21 Feb 2020 17:39:31 +0000 From: "Alexey Melnikov" To: "Phillip Hallam-Baker" Cc: wpack@ietf.org, "The IESG" Content-Type: multipart/alternative; boundary=8cb10974f989454a99e92aa502e74166 Archived-At: Subject: Re: [Wpack] WG Review: Web Packaging (wpack) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 17:40:13 -0000 --8cb10974f989454a99e92aa502e74166 Content-Type: text/plain On Fri, Feb 21, 2020, at 5:26 PM, Alexey Melnikov wrote: > Hi Phillip, > > On Fri, Feb 21, 2020, at 5:23 PM, Phillip Hallam-Baker wrote: >> The signing doc is mentioned in the milestones: >> >> Milestones: >> >> Jun 2020 - Working group adoption of use cases document (will not be >> published as an RFC) >> >> Jun 2020 - Working group adoption of bundling document >> >> Jun 2020 - Working group adoption of security analysis document >> >> Jun 2020 - Working group adoption of privacy analysis document >> >> Jun 2020 - Working group adoption of signing document > > Oh, I see. Yes, I think changing it to "syntax document" is reasonable.. Sorry, I replied too soon. Bundling document is the syntax document. I don't think we need to require a single signing document from the WG, I am happy for the WG to make this decision. Anyway, I will try to improve milestones. Best Regards, Alexey > > Best Regards, > Alexey > >> >> Sep 2021 - Submit the Bundling document to IESG >> >> Mar 2022 - Submit the Privacy analysis document to IESG >> >> Mar 2022 - Submit the Security analysis document to IESG >> >> Mar 2022 - Submit the Signing document to IESG >> >> >> I can't focus enough for wordsmithing at the moment. So I'll withdraw my other points. >> >> Having spent a couple of years playing with this space I think that it is actually quite constrained at a certain level that is a bit more abstract than syntax but still involving the order in which information is presented. If you write out all the maximal requirements, there is only really one way to do it that makes sense. >> >> The only thing that is innovative in my work (DARE) is the way I provide for incremental encryption and the profiling I do on JOSE to provide RAILS like fluency. >> >> >> On Thu, Feb 20, 2020 at 5:14 AM Alexey Melnikov wrote: >>> __ >>> Hi Phillip, >>> Thank you for your comments. My answers below. >>> >>> On Mon, Feb 17, 2020, at 7:52 PM, Phillip Hallam-Baker wrote: >>>> I am a bit fuzzy on the non requirements. In particular, the DRM non requirement. >>>> >>>> If you have a means to publish a compound document as a book and you have a means to protect the privacy of that compound document, you have the ability to encrypt which means that you have a certain level of DRM capability. >>>> >>>> As I see it DRM is a combination of two problems, one control over initial distribution, the second control over redistribution. The second has proved to be infeasible of course but the first is quite tractable. So I think it would be useful to narrow the statement to controlling redistribution. >>> I think the idea is to declare both out of scope, so I would rather not get into details of how DRM might be implemented using the format. So I suggest no change. >>> >>>> What I think is also intended here is that the group does not consider the protocol(s) by which access tokens are exchanged beyond the simplest case of passing a key over a TLS connection. This should probably be stated directly. >>> I am not entirely clear where this text can be inserted. Can you suggest some specific text and where to insert it >>> >>> >>>> Also, I think that rather than a 'signing document', the group really has a syntax document and it is far from clear that there will be only one. My work requires a blockchain type capability, that is incremental authentication and encryption. I certainly plan to re-use the bundling semantics but I can't make use of a syntax that arbitrarily dismisses my core requirements. >>> >>> There is no mentioning of "signing document" in the charter. I think what you propose is a very reasonable thing to discuss in the WG when it is formed. >>> >>> Best Regards, >>> Alexey > --8cb10974f989454a99e92aa502e74166 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, Fe= b 21, 2020, at 5:26 PM, Alexey Melnikov wrote:
Hi Phillip,

On Fri= , Feb 21, 2020, at 5:23 PM, Phillip Hallam-Baker wrote:
The signing doc = is mentioned in the milestones:

Milestones:

=
  Jun 2020 - Working group adoption of use cases document (wil= l not be
  published as an RFC)

  Jun 2020 - Working group adoption of bundling document

  Jun 2020 - Working group adoption of s= ecurity analysis document

  Jun 2020 -= Working group adoption of privacy analysis document

<= /div>
  Jun 2020 - Working group adoption of signing document

Oh, I see. Ye= s, I think changing it to "syntax document" is reasonable..
Sorry, I replied too soon. Bundling document is the synta= x document. I don't think we need to require a single signing document f= rom the WG, I am happy for the WG to make this decision.
<= br>
Anyway, I will try to improve milestones.

Best Regards,
Alexey


Best Regards,
<= div>Alexey


  Sep 2021 - Submit t= he Bundling document to IESG

  Mar 202= 2 - Submit the Privacy analysis document to IESG

  Mar 2022 - Submit the Security analysis document to IESG

  Mar 2022 - Submit the Signing document= to IESG


I can't focus eno= ugh for wordsmithing at the moment. So I'll withdraw my other points.&nb= sp;

Having spent a couple of years playing with this space I think that i= t is actually quite constrained at a certain level that is a bit more ab= stract than syntax but still involving the order in which information is= presented. If you write out all the maximal requirements, there is only= really one way to do it that makes sense.

The only thing that is innovat= ive in my work (DARE) is the way I provide for incremental encryption an= d the profiling I do on JOSE to provide RAILS like fluency.


On Thu, Feb 20, 2020 at 5:14 AM Al= exey Melnikov <aamelnikov@f= astmail.fm> wrote:

Hi=  Phillip,
Thank you for your comments. My answers bel= ow.

On Mon, Feb 17, 2020, at 7:52 PM, Phill= ip Hallam-Baker wrote:
I am a bit fuzzy on the non requirements. In particular, the DRM = non requirement.

If you have a means to publish a compound do= cument as a book and you have a means to protect the privacy of that com= pound document, you have the ability to encrypt which means that yo= u have a certain level of DRM capability.

As I see it DRM is = a combination of two problems, one control over initial distribution, th= e second control over redistribution. The second has proved to be infeas= ible of course but the first is quite tractable. So I think it would be = useful to narrow the statement to controlling redistribution.
I think the idea is to declare both out of s= cope, so I would rather not get into details of how DRM might be impleme= nted using the format. So I suggest no change.

<= blockquote type=3D"cite" id=3D"qt-qt-gmail-m_-1829721059208479480qt">
What I think is also = intended here is that the group does not consider the protocol(s) by whi= ch access tokens are exchanged beyond the simplest case of passing a key= over a TLS connection. This should probably be stated directly. 
I am not entirely clear where this text = can be inserted. Can you suggest some specific text and where to insert = it


Also, I think that rather than a 'signing document', the= group really has a syntax document and it is far from clear that t= here will be only one. My work requires a blockchain type capability, th= at is incremental authentication and encryption. I certainly plan to re-= use the bundling semantics but I can't make use of a syntax that arbitra= rily dismisses my core requirements.
There is no mentioning of "signing document" in the charter= . I think what you propose is a very reasonable thing to discuss in the = WG when it is formed.

Best Regards,
Alexey
=

--8cb10974f989454a99e92aa502e74166-- From nobody Wed Feb 26 15:23:13 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F361B3A0A7E; Wed, 26 Feb 2020 15:23:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: wpack-chairs@ietf.org, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158275938793.2785.11639350703479633599.idtracker@ietfa.amsl.com> Date: Wed, 26 Feb 2020 15:23:07 -0800 Archived-At: Subject: [Wpack] Benjamin Kaduk's Block on charter-ietf-wpack-00-12: (with BLOCK and COMMENT) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 23:23:08 -0000 Benjamin Kaduk has entered the following ballot position for charter-ietf-wpack-00-12: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-wpack/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- It looks like we've gotten some good discussion on the community feedback mentioned in my previous Block, though we may still be waiting for a response on the intent of the "Support books being published in the format" secondary goal. I am not sure how appropriate it is to have milestones for "signing document"s given that we say that WPACK will attempt to reuse work on HTTP signing from HTTPBIS. I think there were some more s/signed/authenticated/ changes that were indicated but not present in the 00-12. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It's not entirely clear to me whether "low latency to load a subresource" fits better as a primary or secondary goal. We say we'll try to have security and privacy properties "as close as practical to TLS 1.3". Do we have a sense for how much distance we are willing to accept (vs. conceding that we cannot uphold our security and privacy requirements and produce something that satisfies the key goals) and still publish? When we say that we will try to "address the threat model of a website compromised after a user first uses the site", I'm not entirely clear on which properties we're trying to preserve in the face of such threats. Regarding the "automatic discovery" non-goal, does this preclude a way for a website to indicate how to retrieve an offline-usable version of a resource when that resource is being fetched "on-line"? Are there other IETF WGs (in addition to W3C and WHATWG) that might have some knowledge about security and privacy models for the web? From nobody Thu Feb 27 06:14:45 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E8F3A09A2; Thu, 27 Feb 2020 06:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=dAKApquK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UzUN4QzW 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 LP_DBJI1h60a; Thu, 27 Feb 2020 06:14:37 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 699E63A099E; Thu, 27 Feb 2020 06:14:34 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id A05B769A; Thu, 27 Feb 2020 09:14:33 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute4.internal (MEProxy); Thu, 27 Feb 2020 09:14:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=meaxoH73xtjAlNHGCYERqp3jB9WoUEe SEDIplhYwXA0=; b=dAKApquKq3dYmr4kfgtzZ7bBn/BBy18jSU9b+1g9JK4bCkG HZslTC/e5TTxa+VvtOuDzsI4PKpR9Epf+VrvIrf6ncItzpYlhLKPGii3IW1j0vKB taxB+nrTHuu4mwFzy801L9xdujQZcsgNLx6rVlaS+XJShbcSq9PCIUIT0goOJ+AK 0np1aonQqfSb7EejsvSPBPERpJvAlDFGf4H3kQHWXkqsNSFOgJcO2L5WZv10Q9JT r9L5iVOlhndh+OiGD3vSwNrWV5mXMMGtnY5AuAzsDjwuex2v4H3GUw36o1YgRDFd cBGmYzBJXZAwe2zd8UF5PwQI/8EqPnfuSucladQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=meaxoH 73xtjAlNHGCYERqp3jB9WoUEeSEDIplhYwXA0=; b=UzUN4QzW1ZJFak8lCh0ymy lJ6nY/4xXaMWUk/NbRHjMtd3GKLQx5A1R4qYnhd4D81DcVpx6TqC1tvbxbUNSAhh BfzwWNatoLDN896mWSG6/IUqRP3aX5f9rjxS2Wt53wYu+Lcmz1qCHCEakwI6edJ9 ImeB5IzNmFril+BTwJbkKzBu2oRDFM15sx7uReKO0bnog4l21rskC7vdMwxhaNRd quLTO4+M3mx3SpOY40FvM7fg2Z3j6XpEyGrbnV0hbhdc/EMXkg+euMl/H/13EYj+ QupjgZ4Z29TXvdXJzV7aQhT5984KSN9sdEfuDqXY7wYx/ofQ1T7Ws7bASoum4mcQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrleeigdeifecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr rghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D6AFD660069; Thu, 27 Feb 2020 09:14:32 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-967-g014f925-fmstable-20200226v1 Mime-Version: 1.0 Message-Id: <9a0f1d89-b830-44c6-9b76-bb2e1e60f0c1@www.fastmail.com> In-Reply-To: <158275938793.2785.11639350703479633599.idtracker@ietfa.amsl.com> References: <158275938793.2785.11639350703479633599.idtracker@ietfa.amsl.com> Date: Thu, 27 Feb 2020 14:13:56 +0000 From: "Alexey Melnikov" To: "Benjamin Kaduk" , "The IESG" Cc: wpack@ietf.org, wpack-chairs@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] =?utf-8?q?Benjamin_Kaduk=27s_Block_on_charter-ietf-wpack?= =?utf-8?q?-00-12=3A_=28with_BLOCK_and_COMMENT=29?= 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, 27 Feb 2020 14:14:39 -0000 Hi Ben, On Wed, Feb 26, 2020, at 11:23 PM, Benjamin Kaduk via Datatracker wrote: > It looks like we've gotten some good discussion on the community > feedback mentioned > in my previous Block, though we may still be waiting for a response on > the intent of the > "Support books being published in the format" secondary goal. As I just replied, I will either take it out or replace this with more specific requirements. > I am not sure how appropriate it is to have milestones for "signing > document"s given that > we say that WPACK will attempt to reuse work on HTTP signing from > HTTPBIS. Whether it is a document that just references HTTPBIS work (and thus a very small one) or a separate document, I think we need a milestone for this. If you can suggest a better name for the milestone to make this clearer, please do. > I think there were some more s/signed/authenticated/ changes that were > indicated but > not present in the 00-12. These should now be fixed. Best Regards, Alexey From nobody Thu Feb 27 07:07:59 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 523593A0B04; Thu, 27 Feb 2020 07:07:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: wpack-chairs@ietf.org, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <158281607227.2144.7066471693425440365.idtracker@ietfa.amsl.com> Date: Thu, 27 Feb 2020 07:07:52 -0800 Archived-At: Subject: [Wpack] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf?= =?utf-8?q?-wpack-00-14=3A_=28with_BLOCK_and_COMMENT=29?= X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 15:07:53 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-wpack-00-14: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-wpack/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- Thanks for all the discussion that happen on the charter so far, unfortunately there are still a few points that are not fully clear to me from a transport perspective: 1) It not clear to me how you plan to address low latency. I assume you don't want to optimise anything in the lower layers but it does sound a bit like it. Can you clarify this point? 2) I think "Being extensible and crypto agile" is a requirement we have for any protocol we design. Is there anything special here, or why is this listed? 3) I also don't really understand this point "Specifying constraints on how clients load the formats without describing specific loading algorithm to help achieve the above goals" Can you further explain? I assume there are no transport implications here but as I'm not sure what is meant, I'd like to double-check! 4) Again here I'm not sure what is meant and I assume you don't plan for any transport protocol changes or extension but double-checking! "Optimize transport of large numbers of small same-origin resources." What does this mean? What's the solution you have in mind? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One editorial comment: I find the chosen form of listing goals rather than writing text that describes the scope of the work not very reader-friendly (at least more the main/key goals). I think text instead of quite short bullet points would be more meaningful and would probably have avoided some of the discussion/confusion we had about this charter. Further I agree with Ben that this part is not very clear and could be better scoped: "Security and privacy properties of using authenticated bundles as close as practical to TLS 1.3 transport of the same resources." From nobody Thu Feb 27 07:21:30 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9343A084C; Thu, 27 Feb 2020 07:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=iSv7RokB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d2wLLeSr 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 jkQdZ9CgxREd; Thu, 27 Feb 2020 07:21:27 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9E93A0845; Thu, 27 Feb 2020 07:21:27 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 03A7D851; Thu, 27 Feb 2020 10:21:25 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute4.internal (MEProxy); Thu, 27 Feb 2020 10:21:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm2; bh=97/0+ tDAi8/iHEl35PUEaqcHNPBAN+KXcn3U0oGL6Wo=; b=iSv7RokBjUMOi+YvRnZc8 Jmn7jaqmPvxEfFtdXav5eWV57MZM+synQRpMmJW19N+B8McmOe7MKWgU5VTTvgOv fV3ijU3jsBefi1LbwTEubLnmcaBNiqYjiiEjORhSBuT5BXG74lunVfMQHabJnK5f CyXc38PgkZROdV0EmGqolCA1bLfxmh4vYLnfeBwDTONOIhlCJJ9bkIJkn7kyl0y1 q/5+AQLepj18CbxdBgDUb02KJQqLoXISg5WqjRDwszjv8ZNtkPEaasZqp4w0XUCo VuKKdDivHuM3PSDbfNm7Ohz2XOv9qJIpVJsVb4o/EYfzhWtNhM7SQ2og9iLM/z93 A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm2; bh=97/0+tDAi8/iHEl35PUEaqcHNPBAN+KXcn3U0oGL6 Wo=; b=d2wLLeSrq5NdfD6PN4MQKHqS0ieVxRuvR3Gs+dv3ConCwMe7shBjN6iJF LUMA/e43OKwle/hSvdwp9LJOTnKuYwNeNYw/l8s79xaFGZRGqukjfb2Fnj0Vgjga Xy2T12gt1gn7gUhkspt8RcMwKuflXPXjGd25LtDQB4BGBs0MoXTkcsSQswQ914ug 09xEn3C6ojFGkNVFzI101iH0Xt9t+SFAPu4jzNIxNsW779hOu4RvUjEd+N3IUBsW Ho3Xa+Gv+th+zP951jdr4TbdI/aZQ4hK0KHhNN/GLvzRTAPZrEN8/yQIUInk0D36 DtYhEAKD28Q/oSCaCrJ1En6WwfsoQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrleeigdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrih hlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F017F66006E; Thu, 27 Feb 2020 10:21:24 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-967-g014f925-fmstable-20200226v1 Mime-Version: 1.0 Message-Id: <9449bb04-4b54-4a50-8273-fb368d91fd8b@www.fastmail.com> In-Reply-To: <158281607227.2144.7066471693425440365.idtracker@ietfa.amsl.com> References: <158281607227.2144.7066471693425440365.idtracker@ietfa.amsl.com> Date: Thu, 27 Feb 2020 15:20:48 +0000 From: "Alexey Melnikov" To: "Mirja Kuehlewind" , "The IESG" Cc: wpack@ietf.org, wpack-chairs@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Wpack] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf?= =?utf-8?q?-wpack-00-14=3A_=28with_BLOCK_and_COMMENT=29?= 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, 27 Feb 2020 15:21:29 -0000 Hi Mirja, I am only replying below to your blocking comments: On Thu, Feb 27, 2020, at 3:07 PM, Mirja K=C3=BChlewind via Datatracker w= rote: > Mirja K=C3=BChlewind has entered the following ballot position for > charter-ietf-wpack-00-14: Block >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut thi= s > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-wpack/ >=20 >=20 >=20 > ----------------------------------------------------------------------= > BLOCK: > ----------------------------------------------------------------------= >=20 > Thanks for all the discussion that happen on the charter so far, unfor= tunately > there are still a few points that are not fully clear to me from a tra= nsport > perspective: >=20 > 1) It not clear to me how you plan to address low latency. I assume yo= u don't > want to optimise anything in the lower layers but it does sound a bit = like it. > Can you clarify this point? WPACK is working on a bundle format, so there is no transport protocol h= ere. Can you suggest how to clarify this? > 2) I think "Being extensible and crypto agile" is a requirement we hav= e for any > protocol we design. Is there anything special here, or why is this lis= ted? Nothing special in this case, but in order to avoid any doubts. > 3) I also don't really understand this point > "Specifying constraints on how clients load the formats without descri= bing > specific loading algorithm to help achieve the above goals" > Can you further explain? I assume there are no transport implications = here but > as I'm not sure what is meant, I'd like to double-check! No transport implications. By "load" this means from disk/web browser ca= che. Does this help? > 4) Again here I'm not sure what is meant and I assume you don't plan f= or any > transport protocol changes or extension but double-checking! "Optimize= > transport of large numbers of small same-origin resources." What does = this > mean? What's the solution you have in mind? I might need Jeffrey's help to reply to this one. I am pretty sure there= are no transport protocol implications. Best Regards, Alexey From nobody Fri Feb 28 13:21:09 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FA83A1E35 for ; Fri, 28 Feb 2020 13:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 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.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=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 Bej6gm1rFwdw for ; Fri, 28 Feb 2020 13:21:00 -0800 (PST) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 EBEC33A0B61 for ; Fri, 28 Feb 2020 13:20:59 -0800 (PST) Received: by mail-qv1-xf32.google.com with SMTP id g16so2055223qvz.5 for ; Fri, 28 Feb 2020 13:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cLwep3cNcgiltt5ZmHD7FRPaJwHMr+MMEFq1NZnG/M8=; b=TRgWiz1JJ2nnLHpqhEH+2eFkQR+/eJF6r4CpVhJzHk9LJv2g7AoG2Jmg4e9RvYKW86 2WQDWiQZQPpJFcLFPFyYz6KQR2qXKZ/YFifUwt3XtkE2vbao80V0eXvf7fzFpMc59U0t 6bD6IKu0DZ6+VN7YB5Qe8Qs+kYHCZVRyp7rH8= 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=cLwep3cNcgiltt5ZmHD7FRPaJwHMr+MMEFq1NZnG/M8=; b=Vdp0At+sMxWiFpqEWMUxboECtIvr3VHrjh7ya0m5PLFsdeSMTLW2Wyfiq8ySa2cW75 wZtM4STZTRNZOKBndVAZk6GJybpD2HFeFJideYMMdNTOa9TIA+ofNgC4Oy0+Ka/omaKZ fVsoEo+maapS79jv0vAQd/BG1mpne+6X8Q1F0pdvFM/3u49+QRtiu0LQq/cB0lGHUKiS zw506uhqQy+0S/X3UCwIEfgmuK9HK4NW0ymWxTw/BU6WLl/4qZpOlEQ3Tr6a+jcNswhP L6kkjQ7pojWeBcq5rnzgPe9UYPCqn7lzorzJLkMY6CqdK3byIRy/TwLFks3YD4G+NWqV euOQ== X-Gm-Message-State: APjAAAVQ2+1gkbAIqYcuHrJunbkoZclvarljkkg2A/QHyDc3I/1S+0fX w8U0nl9F3Rw1813QLqERsa/29htJxZf4GSLcOnbM9Q== X-Google-Smtp-Source: APXvYqw6mU8ILi622Tpnx+iuBTigN6nZMErRNuq1IWUxeePqE27nHZW3ghJPSjoLrbHSlzDKhAUFi4orIZngH0czdwU= X-Received: by 2002:a05:6214:88c:: with SMTP id cz12mr5307131qvb.95.1582924858563; Fri, 28 Feb 2020 13:20:58 -0800 (PST) MIME-Version: 1.0 References: <158281607227.2144.7066471693425440365.idtracker@ietfa.amsl.com> <9449bb04-4b54-4a50-8273-fb368d91fd8b@www.fastmail.com> In-Reply-To: <9449bb04-4b54-4a50-8273-fb368d91fd8b@www.fastmail.com> From: Jeffrey Yasskin Date: Fri, 28 Feb 2020 13:20:47 -0800 Message-ID: To: Alexey Melnikov Cc: Mirja Kuehlewind , The IESG , wpack@ietf.org, wpack-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000e6f975059fa96982" Archived-At: Subject: Re: [Wpack] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf?= =?utf-8?q?-wpack-00-14=3A_=28with_BLOCK_and_COMMENT=29?= 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, 28 Feb 2020 21:21:02 -0000 --000000000000e6f975059fa96982 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 27, 2020 at 7:21 AM Alexey Melnikov wrote: > Hi Mirja, > > I am only replying below to your blocking comments: > > On Thu, Feb 27, 2020, at 3:07 PM, Mirja K=C3=BChlewind via Datatracker wr= ote: > > Mirja K=C3=BChlewind has entered the following ballot position for > > charter-ietf-wpack-00-14: Block > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-wpack/ > > > > > > > > ---------------------------------------------------------------------- > > BLOCK: > > ---------------------------------------------------------------------- > > > > Thanks for all the discussion that happen on the charter so far, > unfortunately > > there are still a few points that are not fully clear to me from a > transport > > perspective: > > > > 1) It not clear to me how you plan to address low latency. I assume you > don't > > want to optimise anything in the lower layers but it does sound a bit > like it. > > Can you clarify this point? > > WPACK is working on a bundle format, so there is no transport protocol > here. Can you suggest how to clarify this? > We could split this into two requirements: >>>>> * When a bundle is streamed, the client must be able to start using a subresource before the entire bundle is downloaded, and for large subresources, before the entire subresource is downloaded. * When a bundle is loaded from random-access storage, the client must be able to use a subresource without necessarily reading the entire prefix of the bundle before that subresource. <<<<< Those were roughly what I had in mind when I wrote "low latency". The current format achieves the first by putting the index of subresources at the start of the bundle (unlike ZIP) and by using https://tools.ietf.org/html/draft-thomson-http-mice-03 to protect subresource integrity. It achieves the second by having an index (unlike multipart/*). > 2) I think "Being extensible and crypto agile" is a requirement we have > for any > > protocol we design. Is there anything special here, or why is this > listed? > > Nothing special in this case, but in order to avoid any doubts. > > > 3) I also don't really understand this point > > "Specifying constraints on how clients load the formats without > describing > > specific loading algorithm to help achieve the above goals" > > Can you further explain? I assume there are no transport implications > here but > > as I'm not sure what is meant, I'd like to double-check! > > No transport implications. By "load" this means from disk/web browser > cache. Does this help? > See also the discussion on the IESG list under "WG Review: Web Packaging (wpack)" and at https://mailarchive.ietf.org/arch/msg/wpack/gokRbg6vSxHz3jC3eqcVhYkIF1s/. > 4) Again here I'm not sure what is meant and I assume you don't plan for > any > > transport protocol changes or extension but double-checking! "Optimize > > transport of large numbers of small same-origin resources." What does > this > > mean? What's the solution you have in mind? > > I might need Jeffrey's help to reply to this one. I am pretty sure there > are no transport protocol implications. > This was about improving compression by letting the compression algorithm keep state across many resources. There have also been a few attempts to get the same benefits in HTTP directly, whose difficulties have led to https://tools.ietf.org/html/draft-handte-httpbis-dict-sec-00. Thanks for the transport-oriented review! Jeffrey --000000000000e6f975059fa96982 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 27, 2020 at 7:21 AM Alexey Me= lnikov <aamelnikov@fastmail.fm= > wrote:
Hi Mirja,

I am only replying below to your blocking comments:

On Thu, Feb 27, 2020, at 3:07 PM, Mirja K=C3=BChlewind via Datatracker wrot= e:
> Mirja K=C3=BChlewind has entered the following ballot position for
> charter-ietf-wpack-00-14: Block
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-= ietf-wpack/
>
>
>
> ----------------------------------------------------------------------=
> BLOCK:
> ----------------------------------------------------------------------=
>
> Thanks for all the discussion that happen on the charter so far, unfor= tunately
> there are still a few points that are not fully clear to me from a tra= nsport
> perspective:
>
> 1) It not clear to me how you plan to address low latency. I assume yo= u don't
> want to optimise anything in the lower layers but it does sound a bit = like it.
> Can you clarify this point?

WPACK is working on a bundle format, so there is no transport protocol here= . Can you suggest how to clarify this?

= We could split this into two requirements:

>>= ;>>>
* When a bundle is streamed, the client must be abl= e to start using a subresource before the entire bundle is downloaded, and = for large subresources, before the entire subresource is downloaded.
<= div>
* When a bundle is loaded from random-access storage, th= e client must be able to use a subresource without necessarily reading the = entire prefix of the bundle before that subresource.
<<<= <<

Those were roughly what I had in mind whe= n I wrote "low latency".

The current for= mat achieves the first by putting the index of subresources at the start of= the bundle (unlike ZIP) and by using=C2=A0https://tools.ietf.org/html/draft-thomso= n-http-mice-03 to protect subresource integrity.

It achieves the second by having an index (unlike multipart/*).

> 2) I think "Being extensible and crypto agile" is a requirem= ent we have for any
> protocol we design. Is there anything special here, or why is this lis= ted?

Nothing special in this case, but in order to avoid any doubts.

> 3) I also don't really understand this point
> "Specifying constraints on how clients load the formats without d= escribing
> specific loading algorithm to help achieve the above goals"
> Can you further explain? I assume there are no transport implications = here but
> as I'm not sure what is meant, I'd like to double-check!

No transport implications. By "load" this means from disk/web bro= wser cache. Does this help?

See also th= e discussion on the IESG list under "WG Review: Web Packaging (wpack)&= quot; and at=C2=A0https://mailarchive.ietf.org/arch/msg/wpack/gok= Rbg6vSxHz3jC3eqcVhYkIF1s/.

> 4) Again here I'm not sure what is meant and I assume you don'= t plan for any
> transport protocol changes or extension but double-checking! "Opt= imize
> transport of large numbers of small same-origin resources." What = does this
> mean? What's the solution you have in mind?

I might need Jeffrey's help to reply to this one. I am pretty sure ther= e are no transport protocol implications.

This was about improving compression by letting the compression algorith= m keep state across many resources. There have also been a few attempts to = get the same benefits in HTTP directly, whose difficulties have led to=C2= =A0https://tools.ietf.org/html/draft-handte-httpbis-dict-sec-00.

Thanks for the transport-oriented review!
Jeffrey
--000000000000e6f975059fa96982-- From nobody Fri Feb 28 13:32:27 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCD03A1E55 for ; Fri, 28 Feb 2020 13:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 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.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=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 QnvNTvUkDY55 for ; Fri, 28 Feb 2020 13:32:23 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 AB2A93A1E54 for ; Fri, 28 Feb 2020 13:32:23 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id v25so3169931qto.7 for ; Fri, 28 Feb 2020 13:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=07d2UPj9zVqyhwAn4aa36pOzdmGzW6ufSC8OFLmbrBc=; b=h6XJDPXJgDI7B1q+/eqSc7lFmhxhQMzG8AL5PI39pFrjWArwx1zHsS9fZ1oqllV9No UvRaZC9++eTae+5wx3fV5EOryyxly08uNxiJbe3ny4HXQMPHdpic/YDw9w9iuTdzfMNd W+URE/tQ29r/Rvnil4xUlh8Igfq9OeDWvpJMA= 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=07d2UPj9zVqyhwAn4aa36pOzdmGzW6ufSC8OFLmbrBc=; b=WH2nODNdg7qKgi0aO4a8RHTt1xHc6AZbyfW2qN9AokIs3vQN2YsYdz584kGigYM0DS qu/aUVpQAtcI4YrUNEqrbrfLp9/pappdeHLemSt8uBXmwkDrrVoUaU/Ucs39nmIALVPd 1ihR3UtcMCFOBX710c8arKZ3Oby3bptLROjiSJYhNmeQrcBmXBXsSti/AoP/88RU5kTM BXFlxGvkpN+d4wPV3nefONtCCBcDCHTrguQ5BN1ZWNFt+ZfJqsnZs9Dm4aKvwSWSjXMM o2WycYPAS3VXsOPjOQAjVIOpG9WKeydHi8kvWVcIsC+QfIF7RbPogLlBCEvIHWwG5JUZ l+rg== X-Gm-Message-State: APjAAAXtYcB/rfDHIe7Sr9IFMtMHp6kO8fIvTCPHpuDU+LoVH5JyuVat aIQyLFZj88jT7lTbgvakpOvekaraRY5+w+f2Ak5jCg== X-Google-Smtp-Source: APXvYqyy/FB9p+p50wgccWwX1p3LLMCr2LRzAdF9kOMKcAfNSxJKVPKLxv+gzdLkQ7koDCVGVfEducLh2GBZSpcvRZs= X-Received: by 2002:ac8:6b5a:: with SMTP id x26mr5998046qts.382.1582925542410; Fri, 28 Feb 2020 13:32:22 -0800 (PST) MIME-Version: 1.0 References: <158281607227.2144.7066471693425440365.idtracker@ietfa.amsl.com> <9449bb04-4b54-4a50-8273-fb368d91fd8b@www.fastmail.com> In-Reply-To: From: Jeffrey Yasskin Date: Fri, 28 Feb 2020 13:32:11 -0800 Message-ID: To: Jeffrey Yasskin Cc: Alexey Melnikov , Mirja Kuehlewind , The IESG , wpack@ietf.org, wpack-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000a9ccd4059fa99277" Archived-At: Subject: Re: [Wpack] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf?= =?utf-8?q?-wpack-00-14=3A_=28with_BLOCK_and_COMMENT=29?= 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, 28 Feb 2020 21:32:25 -0000 --000000000000a9ccd4059fa99277 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 28, 2020 at 1:20 PM Jeffrey Yasskin wrote: > On Thu, Feb 27, 2020 at 7:21 AM Alexey Melnikov > wrote: > >> Hi Mirja, >> >> I am only replying below to your blocking comments: >> >> On Thu, Feb 27, 2020, at 3:07 PM, Mirja K=C3=BChlewind via Datatracker w= rote: >> > Mirja K=C3=BChlewind has entered the following ballot position for >> > charter-ietf-wpack-00-14: Block >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut thi= s >> > introductory paragraph, however.) >> > >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/charter-ietf-wpack/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > BLOCK: >> > ---------------------------------------------------------------------- >> > >> > Thanks for all the discussion that happen on the charter so far, >> unfortunately >> > there are still a few points that are not fully clear to me from a >> transport >> > perspective: >> > >> > 1) It not clear to me how you plan to address low latency. I assume yo= u >> don't >> > want to optimise anything in the lower layers but it does sound a bit >> like it. >> > Can you clarify this point? >> >> WPACK is working on a bundle format, so there is no transport protocol >> here. Can you suggest how to clarify this? >> > > We could split this into two requirements: > > >>>>> > * When a bundle is streamed, the client must be able to start using a > subresource before the entire bundle is downloaded, and for large > subresources, before the entire subresource is downloaded. > > * When a bundle is loaded from random-access storage, the client must be > able to use a subresource without necessarily reading the entire prefix o= f > the bundle before that subresource. > <<<<< > I missed the "whether or not the package is authenticated" aspect. That needs something like: * When a bundle is authenticated, the client must be able to validate the authentication without extra requests over the network. This drives the ability to include certificate chains, SCTs (for certificate transparency), and OCSP responses (for revocation) in the bundle. Jeffrey --000000000000a9ccd4059fa99277 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Feb 28, 2020 at 1:20 PM Jeffrey Y= asskin <jyasskin@chromium.org> wrote:
Hi Mi= rja,

I am only replying below to your blocking comments:

On Thu, Feb 27, 2020, at 3:07 PM, Mirja K=C3=BChlewind via Datatracker wrot= e:
> Mirja K=C3=BChlewind has entered the following ballot position for
> charter-ietf-wpack-00-14: Block
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-= ietf-wpack/
>
>
>
> ----------------------------------------------------------------------=
> BLOCK:
> ----------------------------------------------------------------------=
>
> Thanks for all the discussion that happen on the charter so far, unfor= tunately
> there are still a few points that are not fully clear to me from a tra= nsport
> perspective:
>
> 1) It not clear to me how you plan to address low latency. I assume yo= u don't
> want to optimise anything in the lower layers but it does sound a bit = like it.
> Can you clarify this point?

WPACK is working on a bundle format, so there is no transport protocol here= . Can you suggest how to clarify this?

= We could split this into two requirements:

>>= ;>>>
* When a bundle is streamed, the client must be abl= e to start using a subresource before the entire bundle is downloaded, and = for large subresources, before the entire subresource is downloaded.
<= div>
* When a bundle is loaded from random-access storage, th= e client must be able to use a subresource without necessarily reading the = entire prefix of the bundle before that subresource.
<<<= <<

I missed the &qu= ot;whether or not the package is authenticated" aspect. That needs som= ething like:

* When a bundle is authenticated, the= client must be able to validate the authentication without extra requests = over the network.
=C2=A0
This drives the ability to inc= lude certificate chains, SCTs (for certificate transparency), and OCSP resp= onses (for revocation) in the bundle.

Jeffrey=C2= =A0
--000000000000a9ccd4059fa99277-- From nobody Fri Feb 28 14:10:19 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AA23A1F26 for ; Fri, 28 Feb 2020 14:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 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.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=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 xKLFDLfXT8wm for ; Fri, 28 Feb 2020 14:10:02 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2720A3A1F14 for ; Fri, 28 Feb 2020 14:10:01 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id p62so1835677qkb.0 for ; Fri, 28 Feb 2020 14:10:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GBS1WFJpYBqyvxNnzAM7XEn8hA/N6pm0HIfbFolBRs4=; b=dkNIkF4Nj4FnvHxv5uhqCLUfhvOGijjxdQuKy9I65ZVIZiTn/IODKDuZBxJflZhHEq GIcCOST1JRGutjVJOjs8B+/De0s9TjxLlGxff6QQZm4ahQy4Q1gThjblOgIko2irPSpJ bRklEfjCqj1B8m0e+A5dhpsNgfsAkxNRCRr8Q= 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=GBS1WFJpYBqyvxNnzAM7XEn8hA/N6pm0HIfbFolBRs4=; b=RhtrjnzgAeYf09V35xwbifwNiulMBG0KDPERlcXwqlY9LFchOi+cCunNvIPcLiiGDS 4gmYOOdzFjD3A8uxnhfioWBIC1Ux2hFM2TfdRIoA2oiN/z4cH+pspH5GTMB4q+ZYs569 Louieh7DCD6L+R/wFYtelTAlw7VfdReiVRnjcNqJG5YAuQkxs2e6zh10E/WeMCG21GMs S+5vNhCOsBfQlfRoZ06HeJWDo7CfJrUOSOJ6LYT7vWatALHTtUnWvdv55HsQBN0G40dz YVILds/udQT4n7PTphsC5CVUj8GjwIDN51CafCBEoxWIMj/bXkHJ7fRIGPLihB5HNlpt n6Hw== X-Gm-Message-State: APjAAAVLvJzenh41WDjluYmnqpi/0kzxtkU6fW0mKOZniLZ24hfZmW1d WKqrgJPspLG7ScQ52DGm2Wx8SUxkr7uYoyVNNbvbeXQScAg= X-Google-Smtp-Source: APXvYqzgL2Lwmc8f1wm6wGpj7kmh5FIJ+vKtx2sONK3e0uPO3+dSuAJ/H7DjLvkGgRzLLDf//raw86Opaqa/7hWL3lo= X-Received: by 2002:a37:a7d2:: with SMTP id q201mr6670557qke.144.1582927800613; Fri, 28 Feb 2020 14:10:00 -0800 (PST) MIME-Version: 1.0 References: <158275938793.2785.11639350703479633599.idtracker@ietfa.amsl.com> In-Reply-To: <158275938793.2785.11639350703479633599.idtracker@ietfa.amsl.com> From: Jeffrey Yasskin Date: Fri, 28 Feb 2020 14:09:49 -0800 Message-ID: To: Benjamin Kaduk Cc: The IESG , wpack@ietf.org, wpack-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000433d0c059faa1909" Archived-At: Subject: Re: [Wpack] Benjamin Kaduk's Block on charter-ietf-wpack-00-12: (with BLOCK and COMMENT) 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, 28 Feb 2020 22:10:11 -0000 --000000000000433d0c059faa1909 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 26, 2020 at 3:23 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > It's not entirely clear to me whether "low latency to load a subresource" > fits better > as a primary or secondary goal. > There's tension between "Efficient (binary) storage" and low latency loading, since compressing the whole package as a unit will improve storage but harm random access loading. The WG should be able to discuss that tradeoff instead of having it already answered by the charter's choice to describe low latency as a secondary goal. If we demote both to secondary goals, the charter might be read to imply that we have to achieve TLS 1.3's liveness guarantees by, for example, forcing authentication to happen via an extra online request to the origin server. I'd again like the WG to discuss the tradeoff between the latency harm of that request and its security benefit. We say we'll try to have security and privacy properties "as close as > practical to > TLS 1.3". Do we have a sense for how much distance we are willing to > accept > (vs. conceding that we cannot uphold our security and privacy requirements > and produce something that satisfies the key goals) and still publish? > I think that I'm only pushing to compromise on TLS's liveness guarantee, but I haven't thought about this in detail in a couple months, so I might be forgetting something. When we say that we will try to "address the threat model of a website > compromised > after a user first uses the site", I'm not entirely clear on which > properties we're trying > to preserve in the face of such threats. > I described this in more detail at https://wicg.github.io/webpackage/draft-yasskin-wpack-use-cases.html#name-protecting-users-from-a-com. In particular, a user with an existing relationship with a website shouldn't be compromised by an attacker just because they visited the site once at any point the attacker controlled its frontend. If the attacker gained control of the site's build system instead, or if the attacker keeps control for more than a site-determined amount of time, the user may still be compromised. Does that make sense? I wanted to let the WG help work out exactly what's needed here, but the trend of comments seems to be that we should write my current design for a solution into the charter. If that's the case, I think the "Support signed statements about subresources" goal is actually sufficient for this purpose, and we could remove this item. Regarding the "automatic discovery" non-goal, does this preclude a way for > a website > to indicate how to retrieve an offline-usable version of a resource when > that resource > is being fetched "on-line"? > I don't think it's important to prohibit this WG from discussing that particular kind of link, mostly because I think that discussion will be short: add to https://www.iana.org/assignments/link-relations/link-relations.xhtml or https://html.spec.whatwg.org/multipage/links.html#linkTypes. I wanted to head the WG off from discussing how to find a peer's copy of a resource that the client can't access directly. Maybe we should change the non-goal to "A way to automatically discover the URL for an accessible (retrievable) package that includes specific content that the client can't otherwise access."? Thanks, Jeffrey --000000000000433d0c059faa1909 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 26, 2020 at 3:23 PM Benjamin = Kaduk via Datatracker <noreply@ietf.= org> wrote:
---------------------------------------------= -------------------------
COMMENT:
----------------------------------------------------------------------

It's not entirely clear to me whether "low latency to load a subre= source" fits better
as a primary or secondary goal.

Th= ere's tension between "Efficient (binary) storage" and low la= tency loading, since compressing the whole package as a unit will improve s= torage but harm random access loading. The WG should be able to discuss tha= t tradeoff instead of having it already answered by the charter's choic= e to describe low latency as a secondary goal.

If we demote both to secondary goals, the charter might be read to imply= that we have to achieve TLS 1.3's liveness guarantees by, for example,= forcing authentication to happen via an extra online request to the origin= server. I'd again like the WG to discuss the tradeoff between the late= ncy harm of that request and its security benefit.

We say we'll try to have security and privacy properties "as close= as practical to
TLS 1.3".=C2=A0 Do we have a sense for how much distance we are willin= g to accept
(vs. conceding that we cannot uphold our security and privacy requirements<= br> and produce something that satisfies the=C2=A0 key goals) and still publish= ?

I think that I'm only pushing to = compromise on TLS's liveness guarantee, but I haven't thought about= this in detail in a couple months, so I might be forgetting something.=C2= =A0

When we say that we will try to "address the threat model of a website= compromised
after a user first uses the site", I'm not entirely clear on which= properties we're trying
to preserve in the face of such threats.

I described this in more detail at=C2=A0https://wicg.github.io/webpackage/draft-yasskin-wpack-use-cases.html#= name-protecting-users-from-a-com. In particular, a user with an existin= g relationship with a website shouldn't be compromised by an attacker j= ust because they visited the site once at any point the attacker controlled= its frontend. If the attacker gained control of the site's build syste= m instead, or if the attacker keeps control for more than a site-determined= amount of time, the user may still be compromised.

Does that make sense?

I wanted to let the WG hel= p work out exactly what's needed here, but the trend of comments seems = to be that we should write my current design for a solution into the charte= r. If that's the case, I think the "Support signed statements abou= t subresources" goal is actually sufficient for this purpose, and we c= ould remove this item.

Regarding the "automatic discovery" non-goal, does this preclude = a way for a website
to indicate how to retrieve an offline-usable version of a resource when th= at resource
is being fetched "on-line"?

I= don't think it's important to prohibit this WG from discussing tha= t particular kind of link, mostly because I think that discussion will be s= hort: add to https://www.iana.org/assignments/link-relations/link-rel= ations.xhtml or https://html.spec.whatwg.org/multipage/links.html#linkType= s. I wanted to head the WG off from discussing how to find a peer's= copy of a resource that the client can't access directly. Maybe we sho= uld change the non-goal to "A way to automatically discover the URL fo= r an accessible (retrievable) package that includes specific content that t= he client can't otherwise access."?

Thank= s,
Jeffrey
--000000000000433d0c059faa1909-- From nobody Fri Feb 28 14:38:11 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 538DB3A1F8A; Fri, 28 Feb 2020 14:35:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: wpack@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292931733.19931.15602022889617658390@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:17 -0800 Archived-At: Subject: [Wpack] wpack - Requested session has been scheduled for IETF 107 X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:24 -0000 Dear Alexey Melnikov, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. wpack Session 1 (1:30 requested) Wednesday, 25 March 2020, Afternoon Session I 1330-1500 Room Name: Regency C size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/wpack.ics Request Information: --------------------------------------------------------- Working Group Name: Web Packaging Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 150 Conflicts to Avoid: Chair Conflict: tls mls quic Technology Overlap: acme saag secdispatch dispatch httpbis People who must be present: Sean Turner Alexey Melnikov Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Feb 28 17:54:12 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF373A0906; Fri, 28 Feb 2020 17:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clSMuAxfFJyD; Fri, 28 Feb 2020 17:52:45 -0800 (PST) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 7FD4E3A0904; Fri, 28 Feb 2020 17:52:45 -0800 (PST) Received: by mail-pj1-x102c.google.com with SMTP id a18so1990414pjs.5; Fri, 28 Feb 2020 17:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=N4YHKRA4RVytB2HwkKyqbk4yMsD7ETVl3jY7MxjuewQ=; b=Qsj9mj6vAI8/h5yj38pqrVgGgOsfm7gltwS8Rbq6es11CPaep0pZo6Wxwl7dF0e382 FIJAws4lXaGWD4tqTNoxn21b4p5++tU+gktfjp6gZj7KeV09jMr9vcbehPbda2Gqbb6C mR42D58nEGCO3u4hIRJsQ7zLpR3GBAXVM3WQPGBeXGW0yzUiMinKUdesvEMHGN/xUt/j AtKvP5lPqiRdSvkEGyK1sDmmQYy1xxe/ShNAOPotuqgHYgfbUE0MGilWbSnfZwA6FSZH 2qnvtQkuaxrdsr/ufC+W0I4RY2v/g6Qw7e9nD92eiWqTol4wA+zf7yo3YUdMSGUGaiyU r2ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :mime-version:thread-index:content-language; bh=N4YHKRA4RVytB2HwkKyqbk4yMsD7ETVl3jY7MxjuewQ=; b=lgc993GEG99jFYkrNDGrtLBT2PAHkMHgHNwAjIVlnZq6n1uy5QZrITqOj1VPm/ljoX GPTDTrISVTPHTAS0ZEF9cCCijMkLRKCdbvHgAo9SIKVnkYphQcozql6xbNc/rT2pDNu5 x3YzGawNcoZIa3DcLzGL0BnliZBP1YCK1tiRKIo5wXLWvJ/W8z84GB7R03bTtGj47wTC +3k758m+WS3EA36zvSFvhHC4B4QfmkRAGAHOFP/WbApGBmKFJ1C9pA9EOSPKIgpN5SLd 2ZSincUaPPeHvVb8H5KN6LmnQSqvjEYyE0zZkhqkcMG87pwHzWrTydE8u1lVoDQ6A5+X Krfg== X-Gm-Message-State: APjAAAVkerhX5I7cfx6PC1zPHM9f4pVLIBqucA6SJxwFSZT75wvACHPj aDVkfg0LiW3aVPtOIyptiPE= X-Google-Smtp-Source: APXvYqwtY8U+6ejr3vMDiG0GLc45aTFAISl6uMDMBtr5v1gHCmVEiMGdPOc8HS/sOdGOADNAnzvHkg== X-Received: by 2002:a17:90a:bc41:: with SMTP id t1mr7623385pjv.137.1582941164725; Fri, 28 Feb 2020 17:52:44 -0800 (PST) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id u11sm3734952pjn.2.2020.02.28.17.52.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Feb 2020 17:52:43 -0800 (PST) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: Cc: "'Alexey Melnikov'" , "'Mirja Kuehlewind'" , "'The IESG'" , Date: Fri, 28 Feb 2020 17:52:43 -0800 Message-ID: <007501d5eea2$ef555fc0$ce001f40$@acm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01D5EE5F.E1326DE0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdXujTmUeiJdNx6sSke2PQMP+io9cw== Content-Language: en-us Archived-At: Subject: Re: [Wpack] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Block_on_charter-ie?= =?iso-8859-1?q?tf-wpack-00-14=3A_=28with_BLOCK_and_COMMENT?= X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 01:52:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0076_01D5EE5F.E1326DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The problem WPACK is trying to solve is quite similar to the goals of PDF, with the additional requirements to capture dynamic context. The security and privacy context is different for the bundle than it was for the original content, and what you want is to establish secure provenance. There have been lots of attempts to define packaging formats before only to find they are not suitable for some application which has different requirements. How will WPACK working group resolve this intractable problem of coming to rough consensus of who is in and who is out? Larry ------=_NextPart_000_0076_01D5EE5F.E1326DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The problem WPACK is trying to solve is quite similar = to the goals of PDF, with the additional requirements to capture dynamic = context.

The security and privacy = context is different for the bundle than it was for the original = content, and what you want is to establish secure = provenance.

 

There have been lots of attempts to define packaging = formats before only to find they are not suitable for some application = which has different requirements.

How = will WPACK working group resolve this intractable problem of coming to = rough consensus of who is in and who is out?

 

Larry =

------=_NextPart_000_0076_01D5EE5F.E1326DE0-- From nobody Fri Feb 28 20:04:50 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE43B3A0AFE for ; Fri, 28 Feb 2020 20:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 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.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=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 grDv0BG1rjR1 for ; Fri, 28 Feb 2020 20:04:35 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704B13A0AFD for ; Fri, 28 Feb 2020 20:04:35 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id z19so5104503qkj.5 for ; Fri, 28 Feb 2020 20:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sd6q7tYygRIs7r0L+O5+Ndiw0SC9zXNWd9iBpehr+r4=; b=QljNU9c6olNByJeMDmaoQ+Wks+zUiEFVxZ6Oaw15ArO15wpi+JLt1fiX0pPhkJCVSt 79Ir3IZ0epv3auB9DPuuIj392QRvX7wyqZcv4DKx0Ta8OSCvZx7IM7OjIf8ott6uaa1Z wPZyuzaMCL3chdGTVslb7dEG0A3tjSzq62udQ= 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=sd6q7tYygRIs7r0L+O5+Ndiw0SC9zXNWd9iBpehr+r4=; b=jmEmQo/T+leB2+bJ3Osy/JoB614uBMiDbfU9pDa3rDR5xDMMYyrVuYRo5s8BuyLmVn zePsQfIS1wuf+RF/YaWlpL0VasrZQ+beoEdn6VqRcxnemQIhDoPNUcpuher2B39p7puT JcDItqZer9Fp76BeD28dmlxOGmt66oKhZhsPqXZsgjE+nnKBsnz/rJQivXBR8loAbQz7 AiJdlpM0KyVRbBnjKbkFSTC+I/0l5cZaSfigKXZDGA7kWOxuPucVmnANRmdw30zlqPEM uohlNA30ybWrQIwxU4TJfJIlrVZrp5TpvybwcM0tyxm2Oyxbjiuglxs5wPxraPqA5tJG 9Lrg== X-Gm-Message-State: APjAAAWmN+h9Bi880MsJxOh1hOMnWEPc6SIw8U/jexDnmgYI26C259ko Hs7U6FqPfRWiACe5Ascl+bVNu+zqFq2a1y38/qdAsQ== X-Google-Smtp-Source: APXvYqxG2omWHQXT6nRD6r3GNHCbS2vnexL7aMNXiXn3f81tbcdEKBaQOvXl3ifepKO5DssK2NDuvn/illIpHfW7OUQ= X-Received: by 2002:a37:a503:: with SMTP id o3mr6684251qke.447.1582949074032; Fri, 28 Feb 2020 20:04:34 -0800 (PST) MIME-Version: 1.0 References: <007501d5eea2$ef555fc0$ce001f40$@acm.org> In-Reply-To: <007501d5eea2$ef555fc0$ce001f40$@acm.org> From: Jeffrey Yasskin Date: Fri, 28 Feb 2020 20:04:22 -0800 Message-ID: To: Larry Masinter Cc: Jeffrey Yasskin , Alexey Melnikov , Mirja Kuehlewind , The IESG , wpack@ietf.org Content-Type: multipart/alternative; boundary="00000000000041dc54059faf0d51" Archived-At: Subject: [Wpack] Finding rough consensus about supported use cases X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 04:04:37 -0000 --00000000000041dc54059faf0d51 Content-Type: text/plain; charset="UTF-8" Hi Larry, Don't all working groups have to solve the problem of whose use cases will be met by the solution? We have a charter that describes an initial set of use cases, and for questions within that set, it seems like we have decent mechanisms for discussing whether a proposed use case adds too much complexity to be worth handling. Not everyone will always agree, as happened in https://github.com/httpwg/http-extensions/issues/782, but we can still make progress. The initially proposed format also anticipates some extensibility, so we can come back and add new use cases after the initial format is deployed. If you have a particular application in mind, please let me know. Jeffrey On Fri, Feb 28, 2020 at 5:52 PM Larry Masinter wrote: > The problem WPACK is trying to solve is quite similar to the goals of PDF, > with the additional requirements to capture dynamic context. > > The security and privacy context is different for the bundle than it was > for the original content, and what you want is to establish secure > provenance. > > > > There have been lots of attempts to define packaging formats before only > to find they are not suitable for some application which has different > requirements. > > How will WPACK working group resolve this intractable problem of coming to > rough consensus of who is in and who is out? > > > > Larry > --00000000000041dc54059faf0d51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Larry,

Don't all work= ing groups have to solve the problem of whose use cases will be met by the = solution? We have a charter that describes an initial set of use cases, and= for questions within that set, it seems like we have decent mechanisms for= discussing whether a proposed use case adds too much complexity to be wort= h handling. Not everyone will always agree, as happened in=C2=A0https://github.com/ht= tpwg/http-extensions/issues/782, but we can still make progress. The in= itially proposed format also anticipates some extensibility, so we can come= back and add new use cases after the initial format is deployed.
=

If you have a particular application in mind, please le= t me know.

Jeffrey

On Fri, Feb 28, 2020 at 5:52 PM = Larry Masinter <LMM@acm.org> wrote= :

The problem WPACK is trying to solve is quite similar to the goal= s of PDF, with the additional requirements to capture dynamic context.

The security and privacy context is dif= ferent for the bundle than it was for the original content, and what you wa= nt is to establish secure provenance.

=C2=A0

There have been lots of a= ttempts to define packaging formats before only to find they are not suitab= le for some application which has different requirements.

=

How will WPACK working group resolve this intractabl= e problem of coming to rough consensus of who is in and who is out?<= u>

=C2=A0

Larry

--00000000000041dc54059faf0d51--