Please review HTTP performance aspects of Incremental Font Transfer
Chris Lilley <chris@w3.org> Tue, 28 June 2022 12:38 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
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 A38E0C15D887 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 Jun 2022 05:38:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level:
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 XSX3PnHD0FPH for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 Jun 2022 05:38:18 -0700 (PDT)
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 C0AAFC15D894 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 28 Jun 2022 05:38:18 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1o6AQh-009jEc-Lq for ietf-http-wg-dist@listhub.w3.org; Tue, 28 Jun 2022 12:34:55 +0000
Resent-Date: Tue, 28 Jun 2022 12:34:55 +0000
Resent-Message-Id: <E1o6AQh-009jEc-Lq@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <chris@w3.org>) id 1o6AQg-009jDk-Po for ietf-http-wg@listhub.w3.org; Tue, 28 Jun 2022 12:34:54 +0000
Received: from raoul.w3.org ([128.30.52.128]) by mimas.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <chris@w3.org>) id 1o6AQf-006WTi-JI for ietf-http-wg@w3.org; Tue, 28 Jun 2022 12:34:53 +0000
Received: from athedsl-316181.home.otenet.gr ([85.72.90.179] helo=[192.168.1.7]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <chris@w3.org>) id 1o6AQe-0006E2-DT for ietf-http-wg@w3.org; Tue, 28 Jun 2022 12:34:52 +0000
Message-ID: <5eb29866-36c1-8fe5-0f1b-0d560c2f7dff@w3.org>
Date: Tue, 28 Jun 2022 15:34:49 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.0
Content-Language: en-US
From: Chris Lilley <chris@w3.org>
To: ietf-http-wg@w3.org
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-W3C-Hub-Spam-Status: No, score=-12.9
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, BAYES_00=-1.9, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_DB=-1, W3C_IH=-3, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1o6AQf-006WTi-JI 4342589ca5364772f16975ee2f1379e2
X-Original-To: ietf-http-wg@w3.org
Subject: Please review HTTP performance aspects of Incremental Font Transfer
Archived-At: <https://www.w3.org/mid/5eb29866-36c1-8fe5-0f1b-0d560c2f7dff@w3.org>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40210
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
The Web Fonts WG requests review of the Incremental Font Transfer (IFT) specification by the IETF HTTP WG. A new WD of IFT was published today [1] This specification defines two methods to incrementally transfer fonts from server to client. Incremental transfer allows clients to load only the portions of the font they actually need which speeds up font loads and reduces data transfer needed to load the fonts. A font can be loaded over multiple requests where each request incrementally adds additional data. Earlier work [2] demonstrated the performance improvements in terms of bytes transferred and reduced network delay, for various network types. The current work proposes a specific networking mechanism by which the client and server can negotiate which IFT method to use [3], and to transfer requested subsets of the entire font [4][5]. Note too that Mark Nottingham has raised a performance concern for the Range Request method [6] We would particularly value the review of the IETF HTTP WG on those aspects, although review of the entire specification would of course be most welcome. Please feel free to raise issues on our GitHub repo [7]. [1] https://www.w3.org/TR/2022/WD-IFT-20220628/ [2] https://www.w3.org/TR/PFE-evaluation/ [3] https://www.w3.org/TR/2022/WD-IFT-20220628/#method-selection [4] https://www.w3.org/TR/2022/WD-IFT-20220628/#extend-subset [5] https://www.w3.org/TR/2022/WD-IFT-20220628/#browser-behaviors-subsequent-requests [6] https://github.com/w3c/IFT/issues/74 [7] https://github.com/w3c/IFT/issues/ -- Chris Lilley @svgeesus Technical Director @ W3C W3C Strategy Team, Core Web Design W3C Architecture & Technology Team, Core Web & Media
- Please review HTTP performance aspects of Increme… Chris Lilley
- Re: Please review HTTP performance aspects of Inc… Martin Thomson
- Re: Please review HTTP performance aspects of Inc… Chris Lilley
- Re: Please review HTTP performance aspects of Inc… Martin Thomson