From: Bruce Lilly (blilly@erols.com)
Date: Wed Jan 15 2003 - 08:32:44 CST
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.