From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@listhub.w3.org Mon Mar 4 19:19:41 2024 Return-Path: X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5D6C14F60B for ; Mon, 4 Mar 2024 19:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.754 X-Spam-Level: X-Spam-Status: No, score=-7.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=w3.org header.b="RsigjZgp"; dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=w3.org header.b="PUgts8a0"; dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=google.com header.b="uleVht5/" Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJi3W7ScNeB3 for ; Mon, 4 Mar 2024 19:19:39 -0800 (PST) Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F64C14F5E2 for ; Mon, 4 Mar 2024 19:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Content-Type:To:Message-ID:Date:From:In-Reply-To:References: MIME-Version:Cc:Reply-To; bh=YKtCKzYyh6thtHTWGdUnH9r+6F60nxOLzTrigQnEPSo=; b= RsigjZgpE9yagWBDaRblPHQQJhPtC8DeoPzHaZ2FMVSho2ZdYNSQzSDMkZc7/W1RcDKQETcU65Hof 0Bpj3S0Kwult1tBRdIZ3qx/w1a/R6aB+OC39QOMzDTdkGmVUiPzeYy6XVGLLJREnLsN2mmE7ARrFn si0nVcZyiXhZ9iXbg7BlJrU4nMlwcAwFts6WsK+aZTwSxKy2ZDZxcEv66v/EQ0odtUhMZuQtsuRXA QKx8kzUY4kNwm+XYXKc3w9bPcCpbje+31L9jqPfRcTC1jCLeKsYf51kvqyHCGEvtxaMN4B4mE55Ax Ee5hVTngdGOraeuitcAI8PRluENNNMmpCA==; Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1rhLJ3-001ZBL-T3 for ietf-http-wg-dist@listhub.w3.org; Tue, 05 Mar 2024 03:17:29 +0000 Resent-Date: Tue, 05 Mar 2024 03:17:29 +0000 Resent-Message-Id: Received: from www-data by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1rhLJ1-001ZAR-Nr for ietf-http-wg@listhub.w3.org; Tue, 05 Mar 2024 03:17:27 +0000 Received: from pan.w3.org ([3.222.182.102]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rhLIA-001Z87-2X for ietf-http-wg@listhub.w3.org; Tue, 05 Mar 2024 03:16:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:To:Subject:Message-ID:Date:From:In-Reply-To:References: MIME-Version:Cc:Reply-To; bh=F0r9NPTLZ/GNaRJIbZ7xu4N4xTFKD8EfwxDCRGTr8Ok=; t=1709608594; x=1710472594; b=PUgts8a0NNAAcvjJy/deyAJ3kSBTRNvUcsCPjx85RHOUVOH jIML1EvgBQDOjQzVoHPj+LDXgvkjJ2g4k49TMAKBaJUnGsL4m2XNhr3T/zOSFo6NXLyHqsaT594G0 J2zbzVwxCi2dJZeENXWpNWrzBX/Qgi28oACOEIVidsWBDbqzKth8f8edVGtuA2ReKXCZYxRLGR/ot JK9MObzr0RSjkTlLGrCdafJswtoHKojHZqUJEugoxWgq91sismwlNoqVWyk8qXSOBfPHoXBSRYkZZ f3xbhEMhbXECai7ShydIqhUNu5qb6BHwPR2vqdYH4Ll/Re88Yw1/iudWhLEGbVzQ==; Received-SPF: pass (pan.w3.org: domain of google.com designates 2a00:1450:4864:20::332 as permitted sender) client-ip=2a00:1450:4864:20::332; envelope-from=nidhijaju@google.com; helo=mail-wm1-x332.google.com; Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]) by pan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1rhLI9-007OHJ-0t for ietf-http-wg@w3.org; Tue, 05 Mar 2024 03:16:33 +0000 Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-412a2c2ce88so22535e9.1 for ; Mon, 04 Mar 2024 19:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709608589; x=1710213389; darn=w3.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=F0r9NPTLZ/GNaRJIbZ7xu4N4xTFKD8EfwxDCRGTr8Ok=; b=uleVht5/FaS0AJ+lMoDY7ijYXQxzkr6VUl/DO2dUCsV+LuW5KulwlnB6GlOfg0j2Z0 bSh+ZUIu6j74799jeFNurOi8X5P1MawqSnINQ8uQ1QxY4B/MDRzJAyhyu5eY5/ExZpZW qWBbHEpGMCZJ4bGcfdEIxkjmOX35OXIQJAMUzaVO7sYmdvFc7p+m6IenIhu42krCycx6 BPNP9vq6ynaQa673N3NX8d+J4PKyr+xg3toHSYvgHukzQjdtT4M6SaUlEoms4QOr/Xmm AA3V6PssnJpQp7mAwznvgx57kmISlkEOZa6rFigX6t85KYO4Iq6akOKyTHK/OVbEyxW/ 0elA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709608589; x=1710213389; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=F0r9NPTLZ/GNaRJIbZ7xu4N4xTFKD8EfwxDCRGTr8Ok=; b=PXncP3/V7Jkc0zYuSbuoJBYFYUKxGiqj45pYt7WMaTYlMXaoFY10cJ21uSMzH3EZiC wUiZPju4oQ3C4B9tGSY0bUIicm29Uj4oHz9+L6zD49S++UXlS4bVCx5dJ2pJpuZS1ovd NgoSNnb+B3seR2G/G/P5H2DxvEoQ449Rez3tDOXWlQx3sXjtzOWscHeQON6+3z89ro/5 MEClwLhQpwDO6mX4/A2p/8d+xm/iIE2tAsV8RTJaVLQKuFAzZjWAiz6Ka6aH2dhofdVn eCzGdmJIn0i64OpjGZcxdernzzH8zie7oltYhtTRilfTBIM2DPjqd94gSA1oF34mrl7G He2Q== X-Gm-Message-State: AOJu0YwFlwalouGBOl6mHunUWH1+7jk8AF4iOeGP6Heu7WscHQrzEati eG2HnMs9jAtC6YavSlfDbb4Lt/RjBAsrg+SN9nTuZ7KWknXaZNNbejyOhoLnG2W6ovtHygf4Vmx 3sfrroXLanfjk8BDRMvSxI8hvNVys7vVbeVDFfT3NsLPEilU4w4OF5lM= X-Google-Smtp-Source: AGHT+IFEGyqc+Gu+y8wIMLhOrl5PzJ0KK2zh6rAJE8/uxSmKqcCUSHiKAdL7ixj5m9klmbg9KHRzFO//zHFKUsECcpU= X-Received: by 2002:a05:600c:5106:b0:412:c3d0:593d with SMTP id o6-20020a05600c510600b00412c3d0593dmr14567wms.5.1709608588787; Mon, 04 Mar 2024 19:16:28 -0800 (PST) MIME-Version: 1.0 References: <170959112780.45035.16361642801992496075@ietfa.amsl.com> In-Reply-To: <170959112780.45035.16361642801992496075@ietfa.amsl.com> From: Nidhi Jaju Date: Tue, 5 Mar 2024 12:16:17 +0900 Message-ID: To: ietf-http-wg@w3.org Content-Type: multipart/alternative; boundary="000000000000a418e50612e14400" X-W3C-Hub-DKIM-Status: validation passed: (address=nidhijaju@google.com domain=google.com), signature is good X-W3C-Hub-Spam-Status: No, score=-21.6 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, DMARC_PASS=-0.001, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1 X-W3C-Scan-Sig: pan.w3.org 1rhLI9-007OHJ-0t d1b4a45230320dbc2414040dcf251e58 X-caa-id: 12b1d1f092 X-Original-To: ietf-http-wg@w3.org Subject: Fwd: New Version Notification for draft-jaju-httpbis-zstd-window-size-00.txt Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/51854 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --000000000000a418e50612e14400 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I wrote a draft regarding window sizes in Zstandard Content Encoding that aims to update RFC8878 to require a specific limit for improved interoperability. For context, we recently shipped zstd Content Encoding support in Chrome 123 and came across incompatibilities in the field where developers were confused when their compressed content was not able to be decoded by Chrome, but was correctly decoded by curl and the zstd CLI. Having an explicit agreed-upon limit would help deployers of zstd to align their implementations and cause less user friction. I believe this topic was also previously discussed at https://lists.w3.org/Archives/Public/ietf-http-wg/2021JulSep/0137.html and https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0178.html. This was also discussed at the W3C WebPerf WG meeting at TPAC 2023. Please let us know what you think. Best regards, Nidhi ---------- Forwarded message --------- From: Date: Tue, Mar 5, 2024 at 7:26=E2=80=AFAM Subject: New Version Notification for draft-jaju-httpbis-zstd-window-size-00.txt To: W. Felix P. Handte , Nidhi Jaju A new version of Internet-Draft draft-jaju-httpbis-zstd-window-size-00.txt has been successfully submitted by Nidhi Jaju and posted to the IETF repository. Name: draft-jaju-httpbis-zstd-window-size Revision: 00 Title: Window Sizing for Zstandard Content Encoding Date: 2024-03-04 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/archive/id/draft-jaju-httpbis-zstd-window-size-00.txt Status: https://datatracker.ietf.org/doc/draft-jaju-httpbis-zstd-window-size/ HTML: https://www.ietf.org/archive/id/draft-jaju-httpbis-zstd-window-size-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-jaju-httpbis-zstd-window-size Abstract: Deployments of Zstandard, or "zstd", can use different window sizes to limit memory usage during compression and decompression. Some browsers and user agents limit window sizes to mitigate memory usage concerns, causing interoperability issues. This document updates the window size limit in RFC8878 from a recommendation to a requirement in HTTP contexts. The IETF Secretariat --000000000000a418e50612e14400 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I wrote a draft regarding window sizes= in Zstandard Content Encoding that aims to update=C2=A0RFC8878 to req= uire a specific limit for improved interoperability.

For context, we= recently shipped zstd Content Encoding support in Chrome 123 and came acro= ss incompatibilities in the field where developers were confused when their= compressed content was not able to be decoded by Chrome, but was correctly= decoded by curl and the zstd CLI. Having an explicit agreed-upon limit wou= ld help deployers of zstd to align their implementations and cause less use= r friction.

I believe this topic was also previously discussed at=C2= =A0https://lists.w3.org/Archives/Public/ietf-http= -wg/2021JulSep/0137.html and=C2=A0https://lis= ts.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0178.html. This was a= lso discussed at the W3C=C2=A0WebPerf WG meeting at TPAC 2023.

Please let = us know what you think.

Best regards,
Nidhi
----= ------ Forwarded message ---------
From: <internet-drafts@ietf= ..org>
Date: Tue, Mar 5, 2024 at 7:26=E2=80=AFAM
Subject= : New Version Notification for draft-jaju-httpbis-zstd-window-size-00.txtTo: W. Felix P. Handte <felixh@meta.com>, Nidhi Jaju <nidhijaju@google.com>

A new version of Internet-Draft draft-jaju-httpbis-zstd-window-size-00.txt= has
been successfully submitted by Nidhi Jaju and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0draft-jaju-httpbis-zstd-window-size
Revision: 00
Title:=C2=A0 =C2=A0 Window Sizing for Zstandard Content Encoding
Date:=C2=A0 =C2=A0 =C2=A02024-03-04
Group:=C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 5
URL:=C2=A0 =C2=A0 =C2=A0 h= ttps://www.ietf.org/archive/id/draft-jaju-httpbis-zstd-window-size-00.txt
Status:=C2=A0 =C2=A0https://dat= atracker.ietf.org/doc/draft-jaju-httpbis-zstd-window-size/
HTML:=C2=A0 =C2=A0 =C2=A0= https://www.ietf.org/archive/id/draft-jaju-httpbis-zstd-window-size-00.html=
HTMLized: https://datatrack= er.ietf.org/doc/html/draft-jaju-httpbis-zstd-window-size


Abstract:

=C2=A0 =C2=A0Deployments of Zstandard, or "zstd", can use differe= nt window sizes
=C2=A0 =C2=A0to limit memory usage during compression and decompression.=C2= =A0 Some
=C2=A0 =C2=A0browsers and user agents limit window sizes to mitigate memory= usage
=C2=A0 =C2=A0concerns, causing interoperability issues.=C2=A0 This document= updates the
=C2=A0 =C2=A0window size limit in RFC8878 from a recommendation to a requir= ement
=C2=A0 =C2=A0in HTTP contexts.



The IETF Secretariat

--000000000000a418e50612e14400--