I think it would be most useful to the world of MIME mail if we
adjusted the RFCs so that the definitions of 8bit and binary were more
specific, and specifically, they should include that:
8bit: limited line lengths, specific line-ending chars, char 0 is
evil. 32-126,128-255 are the only valid chars. (I'm negotiable on the
"32-126,128-255" ranges... should they be "32-254"? I don't
know). You might call this "7bit with 32-126,128-255"
binary: 0-255, no restrictions.
Rationale: This documents/tightens up current practices (8bit), and
gives a "no holds bared" goal for the future (binary).
There are many programs that can handle 8bit right now despite the fact
that they were written in the days when uuencode was thought to be the
end-all solution. :-) They are text-based and it would be useful if a
minor effort was needed to let these programs extend their reach to
european char sets and other 8bit-ness. It's not utopia, it's not what
new software should use, but it is there.
The need for a pure "binary" is obvious and I won't describe it.
Real World Example: INN was written to be "8-bit clean except you
can't have char 0 anyplace". Same with C News. MIME'ed netnews just
isn't going to happen without a 8bit option. Neither C News or INN
will support binary until a real need is seen, and right now netnews is
mostly text and 8bit is a reasonable way of doing text. Sure, binary
will come someday, but the way internet software works is you have to
give people a taste before they'll buy the good stuff.
--tal