Nathaniel,
Like all of you feel bound to try and support the 8 bit
kludgery going on in Europe, I have an existing hack that works, and it
will be simplest, given the installed base, to simply bless that for
the time being, especially since my goal is immediate interoperation,
not long term "standards" blessing (the main difference between these
two cases is that what I do now *is* within the SMTP standard). This
means UUENCODE, and an X- type in an RFC1049 Content-Type: header. If
BITNET mangles that, well, that's just tough luck for now. When
RFC-XXXX gets to draft standard, then it'll be time for me to get
together with the SMTP gateway vendors, and get 'em to support the new
standard and the old one for a transition period, with a cut over date
for what gets emitted from the gateways.
Also, don't misunderstand my position in re 8 bit NETASCII.
The Macintosh has its own 8 bit character set that is a superset of
ASCII, and so far as I know, not congruent with any recognized
standard for "national" character sets. I am under tremendous pressure
to support that character set unmolested through SMTP, without encoding.
I suppose I don't object to adding a new command word to SMTP
for that (DAT8 comes to mind), with the understanding that the entire
message must be either transliterated to 7bit ASCII (this is what I do
now in the AppleLink gateway to the Internet - mostly this means that
the diacritical marks disappear, but the goal was to talk to the
Internet, not to macintosh users in particular. I lose some characters
anyway), or entirely encoded if the remote SMTP professes not to
understand the new command.
That still leaves me with a problem - I'll either have to
register the Mac character set somehow so that it's OK to move it
unmolested through 8bit SMTP (which means that people without Macs will
wonder what their European mac correspondents are really saying), or
translate its upper bits to whatever international standard character
set becomes the blessed version of 8 bit text. And back again for
incoming mail? Well, probably in the AppleLink case, yes, since all of
the terminal equipment on AppleLink are Macintoshes. I expect that the
QuickMail and MS/Mail SMTP gateways will work similarly. I'll bet that
still leaves me with some characters that can't be represented,
possibly in both directions. What a mess.
And of course, that doesn't even vaguely handle Farsi, Thai,
Japanese, Hebrew, Chinese, Arabic, etc. They simply must encode,
preferably into something that will pass through 7 bit ASCII, so that
we can support these people on the installed base.
Moving arbitrary bags of bits unencoded through SMTP is madness.
That screams for an entirely new protocol. All of the mailbox formats
and protocols that I know of would have to be changed to hold unencoded
bags of bits (Mark Crispin has been addressing this problem quite well).
If you want to send arbitrary bags of bits *now*, encode, add a
content-type so that you have a unique tag for it, and call it done.
Please don't try to hack this into SMTP - it's too messy.
whew,
Erik E. Fair apple!fair fair(_at_)apple(_dot_)com
P.S. I'm also watching this group with my netnews and NNTP hat on.
Many of the same problems exist there with handling 8 bit text,
and arbitrary bags of bits. However, those of us in the NNTP v2
WG in Atlanta basically said we'd do what you guys do. Unless
it looks like a botch.
(Yes, Greg, I owe you that architecture document).