D. J. Bernstein wrote:
Keith Moore writes:
Which is precisely why 2047 was never intended for anything that needs
to be interpreted by machine.
Even with that (shortsighted) restriction, RFC 2047 was badly designed.
For example, you should have declared encoding in a separate header
field, not by inserting bytes into existing header fields.
That wouldn't work. It's OK to specify body encoding in a header field (as
is done with Content-Transfer-Encoding) because the header always precedes
the body. But header field order can (and does) change, so there's no way
of guaranteeing that a header-encoding header-field would always precede
use of any specified encoding. It also begs the question of what encoding
is used for such a hypothetical header-encoding header field. It also
precludes use of different encodings for different header fields (think of
Resent- fields, for example).
Second-guessing past design in hindsight is one thing. Doing so with an
ill-concieved half-baked purported alternative is another.
> You should
have required 8-bit-clean software in 1991;
And what about networks and charset issues? And how would you magically
change the large installed base of software (not to mention networks)
overnight?
> pandering to 7-bit software
was a huge mistake.
It not just the software...
> You should have required UTF-8 support in 1994. You
should have required UTF-8 as a default in 1998.
UTF-8 does not adequately address i18n issues (language-tsgging), as
per RFC 2277 (1998). RFC 2047 as amended by 2231 (1997) *does* address
i18n issues, including laguage-tagging.