Date: Tue, 4 Jun 1991 19:04:22 -0700 (PDT)
From: Mark Crispin <MRC(_at_)cac(_dot_)washington(_dot_)edu>
Sender: Mark Crispin
<mrc(_at_)tomobiki-cho(_dot_)cac(_dot_)washington(_dot_)edu>
Subject: re: applicability of Rich Text Format for e-mail
To: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
Cc: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu,
moore(_at_)cs(_dot_)utk(_dot_)edu
I thought that the purpose of the QUOTED-PRINTABLE encoding was to deal with
potential problems with sending things such as RTF through e-mail. So this is
not an issue.
Well, I suppose you are right. Actually, the RTF documents I've looked at
aren't
readable by humans at all, so BASE64 (or some compressed encoding) might also
be a
reasonable choice.
What I am dreadfully afraid of is that we will end up being damned for not
using RTF, simply because RTF, like uuencode, is already in widespread use.
I have absolutely no objection to having Microsoft or whoever define an RTF
content-type in a seperate RFC, thereby making it more available. A widely
available standard for portably representing documents as ordinary text files
that
can be shipped through email would be a Good Thing. This might also ease the
integration of PCs and Macs into the Internet world, which would also be a Good
Thing (maybe).
But I don't want to burden all RFC XXXX mail readers with having to understand
RTF. If any kind of rich-text type is standardized, it should one that's easy
to
implement, and also readable by humans using character cell terminals, and/or
lacking fancy mail readers.
I suppose one could also accomplish this with a very minimal subset of RTF,
containing about the same stuff as exists in richmail. Using {\i foo} is almost
as readable as %italic(foo). That would allow RTF readers to display or print
such body parts, but not necessarily to generate them. Serious question: Is
this
a useful feature?
Keith