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