I have to say my views are very close to Keith's. I also know that
Mark Crispin has similar views on this subject.
This is actually an extension of a problem that exists in RFC 822.
822 states that CHAR is 0-127, and that the NUL character is allowed
in both message bodies and headers.
In practice, this is not the case. Few implementations of RFC 822 can
deal with NUL characters in message bodies, even fewer can deal with
NUL characters in headers. Regardless of what 822 actually says, one
cannot send NUL characters around in internet messages and expect
things to interoperate.
Unfortunately, the MIME specs so far have not dealt with this issue.
They currently define 7bit as being 0-127 (like RFC 822) and define
8bit as 0-255. From discussions I've had with some of the people
involved in the original MIME development, I get the impression that
they were aware of this issue, but decided to let it be glossed over.
I think this should be fixed, both in MIME and in 822. NUL-terminated
strings are a programming construct far too common and useful to
effectively outlaw in message handling software. Dealing with
imbedded NUL characters in a language that uses NUL-terminated strings
is far harder than dealing with arbitrarily long lines. 7bit should
be defined as 1-127, 8bit as 1-255, and NUL should be prohibited in
headers.
In any case, implementers would be well advised to label bodies which
contain NUL characters as "binary".
--
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up