Re: applicability of Rich Text Format for e-mail

[Keith Moore <moore@xxxxxxxxxx>]

> Date: Tue, 4 Jun 1991 19:04:22 -0700 (PDT)
> From: Mark Crispin <MRC@cac.washington.edu>
> Sender: Mark Crispin <mrc@tomobiki-cho.cac.washington.edu>
> Subject: re: applicability of Rich Text Format for e-mail
> To: Keith Moore <moore@cs.utk.edu>
> Cc: ietf-822@dimacs.rutgers.edu, moore@cs.utk.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