First on the NULL issue, the problem seems to be moot for email TRANSPORT and
will soon only exist in user agents. Zmailer, Smail, and PMDF are all
binary-transparent. Software.com's SMTP implementation is also
binary-transparent (uses counted strings). Also sendmail 8.7 will handle
NULL (in the message body only) and arbitrarily long lines.
Ahem. We've been over this before quite a few times. When I said that PMDF can
handle NULLs and 8bit, I meant just that and no more. Binary is a completely
different kettle of fish. PMDF, like most of the other agents you list,
performs canonicalization operations on incoming material. It has to because of
the vagarities of the real world. If it isn't line-oriented or if you use CR or
LF for something other than line terminators things will NOT work properly.
If NULL was ever to be removed from the specs, it should have been done 10
years ago when RFC821 and RFC822 were still New Things.
I agree that this would have been best. But it didn't happen, the present
infrastructure doesn't deal with NULs properly (despite your illusions to the
contrary), and saying it should have been fixed years ago is therefore not a
useful contribution.
I also have a few (probably unique :) thoughts on the 7bit/8bit/binary
issue which have been bothering me for a while now:
- While MIME tries to be a transport-independent spec,
it fails at this because of the close ties to SMTP
transport limitations.
This is fundamentally backwards. A specification that doesn't take the
limitations of existing transport into account is absolutely transport
DEPENDENT, in that it can only be used over some new transport that has none of
the existing limitations. By taking the ramifications of existing transports
into account AND allowing for the use of improved transports in the future MIME
achieves a degree of transport independence no other scheme has ever attained.
Sure, it would make MIME a lot prettier if you don't have to deal with today's
busted reality. But it would also make MIME useless.
RFC 822 does not specify a
line length limit of 1000 characters for messages.
So what? Neither does RFC 821, for that matter. And neither does MIME.
Read them and see.
Thus specifying 7bit and 8bit as consisting of lines
no longer than 1000 characters in MIME is not backward-
compatible with RFC822.
Well, since MIME never does this I entirely fail to see what your point is
here.
- Having three "encodings" (Content-Transfer-Encoding)
that mean basically "no encoding was performed"
indicates a design flaw in MIME. (The information
they convey IS necessary, but belongs elsewhere.)
I disagree. I think this is probably the best design choice we ever made in
MIME.
- The only values that should exist for C-T-E are "base64"
and "quoted-printable" since an encoding has actually been
performed (also x-token if an inverse operation needs to
be performed). If no encoding was done, or if no TRANSPORT
has occurred, requiring a C-T-E label for every MIME message
makes no sense. 7bit, 8bit, and binary should not be called
C-T-E's, they are simply an attribute of the "text" or other
object in that MIME section.
And guess what? This is exactly what the specification has always said about
them.
- The "text/" hierarchy already has an implicit means
of specifying whether the text is 7bit, 8bit, or
binary in nature -- that being the "charset" that goes
along with it. Since a UA may not recognize every
charset, a new parameter for text types could be
defined that indicates the structure of the text:
Content-Type: text/plain; charset=us-ascii;
structure=7bit
or
Content-Type: text/plain; charset=UNICODE;
structure=binary
This is only true in some cases, and it is only true of text subtypes in any
case.
- If 7bit, 8bit, and binary labels for structure are found
to be too ambiguous (I think so), then how about this:
Content-Type: text/plain; charset=iso-8859-1;
width=85; range=1-255;
This goes too far and leads to silly states, where the labels do not reflect
reality. So do 7bit, 8bit, and binary, for that matter, but you have to balance
what information should be provided and what should not. You could put a
frequency table in there if it came right down to it.
I think MIME is "just right" right now in this regard.
Ned