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"
No thanks. I don't want to keep using broken transport anymore.
So,
7bit: 0-127, limited line length (1000+), CRLF terminated,
MUST be but IS NOT safe.
8bit: 0-255, limited line length (1000+), CRLF terminated,
MUST be and IS safe.
binary: 0-255, no restrictions, MUST be and IS safe.
Rationale: This documents/tightens up current practices (8bit),
No, your 8bit is no good even for the currently practiced encoding.
On the other hand, if the current practice includes some half broken
implementation of 8bit, it should be labeled as 7bit which itself
cause no interoperabilitty problems (save that QP is virtually unusable).
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.
As discussed recently, there is no need to use MIME for 8bit news.
Masataka Ohta