In the latest draft, as you probably noticed, there is a new mail type
defined, the "Richmail" (default) subtype of "text-plus". The idea of
text-plus came out of some off-list discussions about the distinction
between readable (text-like) unrecognized content-types and unreadable
(binary) content-types. The idea of the richmail subtype was my own
private little brainstorm.
Since the latest draft went out, there's been nothing on the mailing
list about richmail, but a few people have sent me private mail.
Interestingly enough, they all said more or less the same thing, which I
would summarize as "this is a really neat idea, but I think it will be
controversial, and we should probably leave it out of the RFC if some
people want to fight over it." So far, however, nobody has actually
expressed a desire to fight over it, and I'd like to offer a public
explanation of why I want it to be in the RFC.
First of all, a dirty litle secret from the Andrew project: We like to
talk about multimedia mail, and how much people use the "advanced"
features of Andrew mail. Then we like to demonstrate these advanced
features, which include multifont formatted text, pictures,
spreadsheets, animations, and so on. However, the truth -- which we
don't lie about but rarely volunteer -- is that the VAST majority of all
the non-plain-text mail that people send with Andrew uses multiple fonts
and other simple formatting, but none of the fancier stuff. In other
words, multifont text is *really* useful in email, while the verdict is
arguably still out on most of the other stuff. (If you don't believe
you'd find multifont text useful in email, think about how many times
you've done things like the "VAST" and "*really*" in the previous
sentences. With multiple fonts, you could have used bold, italic, or
bigger fonts, and you could have put this parenthesized comment in a
smaller font. People really do this sort of thing all the time if they
have the capability.)
The idea of richmail is to make this functionality more widely
available. To oversimplify, if 95% of the real value of fancy mail like
Andrew is in the 5% of the code that gives you multiple fonts, there's a
lot to be said for trying to define a simple standard mechanism for just
the multiple fonts. To that end, I designed the richmail type to be as
simple and easy to implement as I could possibly manage. It
specifically isn't intended to compete with a more complete and complex
document format such as ODA, but is designed to be usable even in the
smallest and simplest of mail systems. As such, it has a real chance, I
believe, of providing a %italic(lingua franca) (you get the idea) for
multifont text. The reason I want to keep it in this RFC is,
obviously, to increase the likelihood of its widespread implementation.
I've produced a C program that converts "richmail" to plain text, which
is the way you'd want to display it with a vanilla dumb terminal's mail
reader. That program is only 38 lines long, which I think validates my
claim that it is really simple for any mailer to provide this kind of
minimal support. I've appended the program below (it converts richmail
stdin to plain text stdout), and if people think it makes sense I'd be
happy to include it in the RFC, too.
Having said all that, I come to my question: Is there actually any
strong opposition to including this in the RFC? Are there, on the
other hand, people who agree with me that this is worth trying out, to
see if it flies? So far, the only comments I've gotten are of the form,
"I like it, but I fear other people won't." If there are objections,
I'd like to hear about them, but in the absence of objections I'd really
like to keep it in the RFC!
The 38 line richmail-to-plain-text follows below. I realize that it
isn't the most readable C code in the world, mostly, I suspect, because
I was mildly obsessed with making the value that turned out to be "38"
as small as possible. (Actually, 2 of the 38 lines are blank...)
Cheers. -- Nathaniel
#include <stdio.h>
#include <ctype.h>
#define MAXENVS 250 /* This is the maximum environment nesting depth. */
int stacksize=0, visible = 1, EnvStack[MAXENVS]; /* No limit would be better.*/
main() {
char c, token[50];
int i, sawnewline = 0;
while((c = getc(stdin)) != EOF) {
if (c == '%') {
i = sawnewline = 0;
c = getc(stdin);
if (c== '%' || c == ')' || c == '(') {
if (visible) putc(c, stdout);
} else {
do {
token[i++] = isupper(c) ? tolower(c) : c;
} while ((c=getc(stdin)) != '(');
token[i] = NULL;
EnvStack[stacksize] = strcmp(token, "invisible") ? 0 : 1;
if (EnvStack[stacksize++]) visible = 0;
}
} else if (stacksize>0 && c == ')') {
sawnewline = 0;
--stacksize;
visible = 1;
for (i=0; i<stacksize; ++i) if (EnvStack[i]) visible = 0;
} else if (visible && c=='\n') {
if (sawnewline) putc(c, stdout);
sawnewline = 1;
} else if (visible) {
putc(c, stdout);
sawnewline = 0;
}
}
putc('\n', stdout); /* for good measure */
}