At 5:43 PM 10/27/94, Rick Troth wrote:
This is a real problem for me. If you had labled it text/plain
then I could handle it on CMS w/o going through hoops. Remember, we're
trying to make life simple for the users; I'm a systems programmer.
If I get an RTF file in "binary" form I'll just FTP it in binary or
otherwise convert it.
I personally would like to see the spec clarified regarding CTE: binary. I
believe that "binary" mode FTP and MIME's "binary" CTE are two very
different things.
"binary" mode FTP means "do not do newline canonicalization". I believe
MIME's "binary" CTE means nothing of the sort. Canonicalization is a
property of the content-type, not the CTE. Canonicalization SHOULD be done
to text/plain parts, REGARDLESS of the CTE.
So CTE: binary should NOT signal your MTA's or MUA's not to convert
character sets or newlines. All it means is that you're not going to be
seeing very many newlines, and you may see 8-bit chars.
I'd prefer if you just send CT text/plain without any CTE.
The absence of a CTE header is synonymous with CTE: 7bit. Short lines,
only US-ASCII. That does not accurately describe an RTF file with long
lines. So, alas, I cannot help you.
(quoted-printable is
just plain weird when it comes through a gateway; there's no telling
about that line-end; and it's not just EBCDIC gateways that munge it)
The QP spec is implementable; there is no excuse for broken
implementations. It is one thing to have to jump through hoops to be
compatible with old non-MIME mailers; I can (grudgingly) live with that.
But I really do NOT want to have to put up with broken MIME mailers. Stop
them before they munge again! :-)
--
Steve Dorner, Qualcomm Incorporated. "Oog make mission statement."