Re: Libraries assuming iso-8859-1 (was: Re: Consensus call to include Display Strings in draft-ietf-httpbis-sfbis)
Mark Nottingham <mnot@mnot.net> Tue, 30 May 2023 01:04 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 4B96AC15107E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 May 2023 18:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.237
X-Spam-Level:
X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RAZOR2_CF_RANGE_51_100=1.886, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b="eenkntRA"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="a/X4zD1X"
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 EHe3ED6x3Ug5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 May 2023 18:04:48 -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 05B70C14F75F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 29 May 2023 18:04:47 -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 1q3nkd-00GEkO-GI for ietf-http-wg-dist@listhub.w3.org; Tue, 30 May 2023 01:02:15 +0000
Resent-Date: Tue, 30 May 2023 01:02:15 +0000
Resent-Message-Id: <E1q3nkd-00GEkO-GI@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <mnot@mnot.net>) id 1q3nkc-00GEjR-91 for ietf-http-wg@listhub.w3.org; Tue, 30 May 2023 01:02:14 +0000
Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by titan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <mnot@mnot.net>) id 1q3nka-00ARlP-E7 for ietf-http-wg@w3.org; Tue, 30 May 2023 01:02:13 +0000
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CF4825C00D7; Mon, 29 May 2023 21:02:08 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 29 May 2023 21:02:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1685408528; x=1685494928; bh=ZP euLW5Rn3IRFouvevfX50EfKrGkomqA+waxpPCTADc=; b=eenkntRACl9FmZqsYj kcKOAEMuIpKiwhex4hflfMV0gZJpsVQNvh8i1Qsu1QICxVk1nxlrEKH67+MkFZ+n cAQwAyOU3qv1jyotrpFJ2MbfylHpUdvCouP7rDEtJq5R2/sgiFy+WIMW8Kxy5Wjt Mh2rO2q/AqWoMLMLXfxZpqEb6WdkyGOjQNQsdhPrtAWWF1aJUeA+H2wZ4PD5gpTu bzUhkjOj+TEz6YnXI1JEbKybDYUgM+gWvQr3AYXb9YDP0SfaFoWXOJ0KOKgNJvZc qxPdH7W07N6SrKJH/JRwjO00dLQeFNS+tw3G5j5KmLhNdY6pcfpIZuou6V5kNrEn jCDg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1685408528; x=1685494928; bh=ZPeuLW5Rn3IRF ouvevfX50EfKrGkomqA+waxpPCTADc=; b=a/X4zD1XUCKruEsOMs192De4Iffdk OyRstEXaJLBA8IiP/I6nckIkbzJPLfI4pMDpWbK8aAuNPhcmLfuKEp0DMXtcbjib ErxJ3IRNJFybEaUIss26EaRuL85zkoW786uQtL1L18seZaAW1Rpd5Ah6lA9vJg5k jp6pdWdSNrrwmsARYtX9eR2ngBem1myf04XUo+u5gKCh3ttowScMr28cesCgqUWw r0FGYIO5Owc3r/2kLkZ4XFPFlN/vuS/5HDXVuEKcNdu6XwZrwb4/+CslV+JROQ2d X6gEW+Hgft8J5K5M3PZrynv3EhZG3eCr4l/IPCfsyg81GNKTxRSQ5/AYw==
X-ME-Sender: <xms:EEt1ZO2PwggU758mC4ODQDeCo59VXwxOHdOOEzxJ21AemiGqy42Chg> <xme:EEt1ZBFSmAS4VLiKZOJo2OqcOq_c66TwhdZaZIrkcNZn_rj6rXQDLZYsZ5I0K4ara 5cuIsRJ3h-90yjxOw>
X-ME-Received: <xmr:EEt1ZG6PoivnEmhMrKtmKvaB17y9Cu0GwMju6p6PKh7VV5rW2k0l_tRYJdpl2KqGF5jFkIWjY2VAZGpQQZpJ80bGU81E6anL__YLWMMy3Pzfx-mJmi9zkwgo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeekiedggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgevvfhfofesrgdtmherhhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeehleejkeeftdejieduvdehtdeukefgveejfedvueejffekieekveevfeetieel keenucffohhmrghinhepmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:EEt1ZP1RX4MawUFTosOFHU_dOeELbcmQ9zhSfmOCGPhTirro1ZAcHg> <xmx:EEt1ZBH7vsphshmfuWevTvKWyG7zbnfg3j7q32YQRn7LJrWan3UTYg> <xmx:EEt1ZI_IdJuO64lEjkAjsyG6EHSFq51OUI0Qn7C1v81OZBBUhq_j0Q> <xmx:EEt1ZEPsPMxAgtIBZYvy3SIML2WQtJDHTqzIiIzesQwRThXMmVbuJQ>
Feedback-ID: ie6694242:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 29 May 2023 21:02:07 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Message-Id: <A4EFEB4B-7281-4EA5-9A79-1D6797936B9C@mnot.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8D1DAC36-4C9F-44F7-B671-0B2A75345FB7"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Tue, 30 May 2023 11:02:03 +1000
In-Reply-To: <72ddfd05-4fbe-410d-8dd2-6abcc0410917@app.fastmail.com>
Cc: ietf-http-wg@w3.org
To: Martin Thomson <mt@lowentropy.net>
References: <FC5270AF-509C-4331-AE8F-1F2D51BBC5F2@apple.com> <C687C218-7793-4B74-BB51-B7C34059F9C4@gbiv.com> <F84B0780-7710-4F74-9830-ECBD4A926C3D@mnot.net> <c81e6562-7927-a342-9032-df69aba4ad43@it.aoyama.ac.jp> <E80E63C6-639E-41CC-BD40-6EA698092C14@mnot.net> <72ddfd05-4fbe-410d-8dd2-6abcc0410917@app.fastmail.com>
X-Mailer: Apple Mail (2.3731.600.7)
Received-SPF: pass client-ip=66.111.4.28; envelope-from=mnot@mnot.net; helo=out4-smtp.messagingengine.com
X-W3C-Hub-DKIM-Status: validation passed: (address=mnot@mnot.net domain=mnot.net), signature is good
X-W3C-Hub-DKIM-Status: validation passed: (address=mnot@mnot.net domain=messagingengine.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-7.0
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=1.886, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1q3nka-00ARlP-E7 c818047a7f47b266850319387d8d583e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Libraries assuming iso-8859-1 (was: Re: Consensus call to include Display Strings in draft-ietf-httpbis-sfbis)
Archived-At: <https://www.w3.org/mid/A4EFEB4B-7281-4EA5-9A79-1D6797936B9C@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51125
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>
> On 30 May 2023, at 5:04 am, Martin Thomson <mt@lowentropy.net> wrote: > > On Mon, May 29, 2023, at 02:16, Mark Nottingham wrote: >> So, while I think it would be great if we could use UTF-8 in HTTP >> fields directly, I agree with Julian's characterisation of this as >> appropriate for an experiment, not something that we should include in >> infrastructure like SF -- implying that it has to be very highly >> reliable. > > I'm inclined to agree. But, if we proceed with %"..%xx." now, what would UTF-8 look like? "ε", %"∝", or something new like '§'? I would like to run that experiment: it would be the most efficient and most natural thing to do, but I share at least some of your concern about the risks (which are largely a function of middleware: CDNs, stacks, WAFs, etc...). That is tempered by Roy's points about the feature being introduced alongside a feature. Upgrading software should be justifiable if the feature provides enough incentive; but would we want to deploy a new valuable feature with something like this that might add deployment hurdles? > > What might we also do to prepare for such an experiment? Preparation can make success more likely. It seems to me like maybe specifying the new type now is how you get the new type recognized ahead of the time that you run the experiment. Keep in mind that %"" doesn't have an immediate customer either. This is a very good question; I'm not sure what the answer is. In my mind, anything in SF should be _very_ solid; that rules out putting it in the spec alongside %"...". Could we write a separate spec that defined a SF extension that has to be explicitly referenced, and that explains the limitations? -- Mark Nottingham https://www.mnot.net/
- Consensus call to include Display Strings in draf… Tommy Pauly
- Re: Consensus call to include Display Strings in … Julian Reschke
- Re: Consensus call to include Display Strings in … Mark Nottingham
- Re: Consensus call to include Display Strings in … Poul-Henning Kamp
- Re: Consensus call to include Display Strings in … Martin Thomson
- Re: Consensus call to include Display Strings in … Mark Thomas
- Re: Consensus call to include Display Strings in … Roy T. Fielding
- Re: Consensus call to include Display Strings in … Poul-Henning Kamp
- Re: Consensus call to include Display Strings in … Mark Nottingham
- Re: Consensus call to include Display Strings in … Poul-Henning Kamp
- Re: Consensus call to include Display Strings in … Julian Reschke
- Re: Consensus call to include Display Strings in … Julian Reschke
- Re: Consensus call to include Display Strings in … Mark Nottingham
- Re: Consensus call to include Display Strings in … Glenn Strauss
- Re: Consensus call to include Display Strings in … Poul-Henning Kamp
- Re: Consensus call to include Display Strings in … Mark Nottingham
- Re: Consensus call to include Display Strings in … Poul-Henning Kamp
- Re: Consensus call to include Display Strings in … Ilari Liusvaara
- Re: Consensus call to include Display Strings in … Roy T. Fielding
- Re: Consensus call to include Display Strings in … Mark Nottingham
- Re: Consensus call to include Display Strings in … David Benjamin
- Re: Consensus call to include Display Strings in … Willy Tarreau
- Re: Consensus call to include Display Strings in … Martin J. Dürst
- Re: Consensus call to include Display Strings in … Julian Reschke
- Re: Consensus call to include Display Strings in … Michael Sweet
- Re: Consensus call to include Display Strings in … Willy Tarreau
- Re: Consensus call to include Display Strings in … Julian Reschke
- Re: Consensus call to include Display Strings in … Mark Nottingham
- Re: Consensus call to include Display Strings in … Willy Tarreau
- Libraries assuming iso-8859-1 (was: Re: Consensus… Martin J. Dürst
- Re: Libraries assuming iso-8859-1 (was: Re: Conse… Poul-Henning Kamp
- Re: Consensus call to include Display Strings in … Martin J. Dürst
- Re: Consensus call to include Display Strings in … Martin J. Dürst
- Re: Consensus call to include Display Strings in … Willy Tarreau
- Re: Libraries assuming iso-8859-1 (was: Re: Conse… Julian Reschke
- Re: Consensus call to include Display Strings in … Julian Reschke
- Re: Consensus call to include Display Strings in … Julian Reschke
- Re: Libraries assuming iso-8859-1 (was: Re: Conse… Mark Nottingham
- Re: Libraries assuming iso-8859-1 (was: Re: Conse… Martin Thomson
- Re: Libraries assuming iso-8859-1 (was: Re: Conse… Mark Nottingham
- Re: Consensus call to include Display Strings in … Kazuho Oku
- Re: Consensus call to include Display Strings in … Tommy Pauly
- Re: Consensus call to include Display Strings in … Mark Nottingham
- Re: Consensus call to include Display Strings in … Poul-Henning Kamp
- Re: Consensus call to include Display Strings in … Ilari Liusvaara
- Re: Consensus call to include Display Strings in … Poul-Henning Kamp
- Re: Consensus call to include Display Strings in … Ilari Liusvaara
- Re: Consensus call to include Display Strings in … Poul-Henning Kamp