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

[Adam Roach <[e-mail]>]

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.

/a