Re: [I18ndir] Review volunteer needed (Fwd: [dispatch] WGLC of draft-ietf-dispatch-javascript-mjs-07)

Adam Roach <> Fri, 01 May 2020 01:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 033B23A0788 for <>; Thu, 30 Apr 2020 18:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.078
X-Spam-Status: No, score=-2.078 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, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RMxjYUgDford for <>; Thu, 30 Apr 2020 18:28:08 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E65633A0787 for <>; Thu, 30 Apr 2020 18:28:07 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 0411RruL099705 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 30 Apr 2020 20:27:55 -0500 (CDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1588296475; bh=n1l7WqHGkMsyB2KSq+WVzs3QoQXzJSTyC+reyhumOFU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=dPjND24xXG1W5tWUu4v4MvCkr6ueFZcIPtwtHSm1O5k12b0pOQZ8B4foxAWA3IqDF WT4JBLGG0igBdwzVSHIqf5mmPcLoeRBs3fzHOBjieYPB9BPqVJUokDcYPCRGlUWfBO wyUkxynsr2BFmgnSKqNCs2aZire+FhG+ok4YWBzk=
X-Authentication-Warning: Host [] claimed to be []
To: John R Levine <>, Pete Resnick <>
References: <20200430014516.01551188B50A@ary.qy> <> <7AD06F46449F354499AC2E24@PSB> <> <alpine.OSX.2.22.407.2004301241440.26342@ary.qy> <> <477C5A18357719590D6336D9@PSB> <> <alpine.OSX.2.22.407.2004302039080.28451@ary.qy>
From: Adam Roach <>
Message-ID: <>
Date: Thu, 30 Apr 2020 20:27:47 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.OSX.2.22.407.2004302039080.28451@ary.qy>
Content-Type: multipart/alternative; boundary="------------95B2A4B5CDA56DE3EEAFA520"
Content-Language: en-US
Archived-At: <>
Subject: Re: [I18ndir] Review volunteer needed (Fwd: [dispatch] WGLC of draft-ietf-dispatch-javascript-mjs-07)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 May 2020 01:28:10 -0000

On 4/30/2020 7:52 PM, John R Levine wrote:
> I'm wondering if the BOM hack is an ancient workaround for bugs in 
> some server in the 1990s that gave you UTF-16 regardless of what you 
> asked for, perhaps early versions of IIS. I hope no living web server 
> is still that broken. 

For what it's worth, the vast, /vast/ majority of these kinds of 
workarounds are not due to bugs in servers.

They're due to /misconfigured /servers that early, buggy, and extremely 
popular OS-integrated clients (which broadly ignored content 
information, happily rendering, e.g., "text/plain" as a JPEG image in 
certain contexts) didn't complain about. To remain compatible with these 
servers, subsequent browsers have had to perpetuate these bugs; and 
because of this permissiveness, administrators in 2020 continue to 
persistently misconfigure servers: they don't see any errors from doing 
so. Fixing these problems would require a flag day -- coordinated with 
1.7 billion websites -- after which browsers wouldn't put up with this 
kind of content mislabeling. Even though those specific browsers that 
led us to this swamp have been EOL for nearly two decades, that kind of 
massive coordination still remains infeasible.

Nearly all of the MIME-specific issues cited on this list so far have 
this as their explanation. It's an absolute cornucopia of ugliness, and 
everyone involved with the situation is painfully aware of how bad it is.

Permissive MIME handling in early web browsers remains a vivid 
demonstration of how aggressive application of Postel's Maxim at scale 
in widely-used consumer products necessarily ossifies an ever-increasing 
set of historical product bugs into protocols indefinitely. Although not 
cited directly, this specific mess was instrumental in the development 
of the advice in draft-iab-protocol-maintenance.

In terms of what draft-ietf-dispatch-javascript-mjs should say, there 
are two disjoint paths we can decide to follow. The IETF can either 
document a fantasy world of platonic solids that we all wish existed, 
which would have virtually no practical application to implementors; or 
the IETF can document the world as it exists today, warts and all, with 
decades of baked-in unfortunate implementation decisions, and enable 
actual interoperability.

Given this history, the two goals of producing a useful document and an 
ideologically pure document are in diametric opposition. I would hope we 
ultimately decide to do the former rather than the latter, and encourage 
the directorate to steer its feedback to the working group in a way that 
helps achieve this goal.