Keith Moore writes:
The burden on those who want to see raw utf-8 in message headers is to
convincingly demonstrate how to make it work well, without breaking the
installed base.
It works just like other mandatory protocol extensions. Readers are
upgraded to support the extended format; once that's complete, writers
can safely use the format. Examples:
* SMTP clients looking at DNS records were upgraded to understand MX
records. Once that upgrade was complete, SMTP server administrators
were able to safely use MX records.
* The extension under discussion: Message handlers that have trouble
with UTF-8 will be fixed. Once that's complete, message generators
will be able to safely use UTF-8.
* A different extension aimed at the same goal: Message handlers
could be taught some archaic 7-bit GoofyCode format, with certain
complicated rules for figuring out which parts of a message header
are subject to GoofyCode processing. If that were ever completed,
message writers would be able to safely use GoofyCode.
If you're complaining about the possibility that someone uses a format
before it is universally supported---perhaps causing failures---then
you're a hypocrite. Your own RFC 1342, a predecessor to GoofyCode, has
caused tremendous damage in exactly this way for the past ten years,
yet you continue to support GoofyCode-style proposals such as IDNA.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago