Perhaps it is time to summarize the simplemail debate, listing
conclusions and open issues.
______________________________
Simplicity and Readability
Some writers here have suggested that the markup scheme be simple
enough that people can create marked up text with ordinary, fixed
width editors. They and others argue that the standard should also be
simple enough that messages can be understood with the same
old-fashioned tools.
This seems to me a crucial point. The simplemail proposal only makes
sense if we postulate that the sender, the reader, or both are using
plain-ASCII (or EBCDIC or 8859 or ...) text processors; not user
agents. If both are using MIME user agents, they can just as well use
richtext.
______________________________
Compatibility and Phase-in
Since I do some of my correspondence with a MIME user agent, I have
become acutely conscious of the fact that many recipients are not
using such agents. It is a corollary of the Simplicity issue that the
simplemail scheme should enhance communication between two people who
do not both have the same user agent.
______________________________
Header
Is it simplemail only if it has a content-type header? Consider these
cases:
-o When a MIME user agent sends a message, does it get converted to
simplemail (in those cases where simplemail is sufficient to fully express
the functionality?) Presumably the agent inserts a content-type header.
-o When a user creates a simplemail compliant message with a non-MIME
agent, does a content-type header HAVE to be put on? (Of course not.)
-o When a MIME user agent receives a simplemail compliant message
lacking a content-type header, does it interpret the simplemail
markup and produce a formatted, filled message?
-o Suppose a user tries to send a simplemail message and includes a
content-type header, but the message is in fact not compliant. Then
what should the user agent do?
My own prejudice is to have incoming mail displayed in as readable a form
as possible, independent of the capabilities of the equipment with
which the sender created it. I want *all* my incoming messages to be
processed as if they are simplemail, if not otherwise marked. My user
agent must also provide a button so I can quickly see the raw form of
the message in case of questions.
I do not want to be required to have to insert a special header to
have the mail I send from csh be interpreted as simplemail. (And
consequently, I believe the scheme should be devised so that errors
are (a) unlikely, and (b) easy for the parser to recover from
gracefully.)
______________________________
When is simplemail used?
Usually, I claim, mail should be converted to simplemail form, where
no more elaborate formatting is required. This has evoked the
objection that MIME is employed for document interchange and the
original formatting should be retained in that case. I don't think
these constraints are in conflict. The user must take some action to
incorporate a document into a message and this action ought to trigger
the generation of a multi-part/alternative message with the original
fomratting intact.
______________________________
Robust encoding
The syntax of markups should be such that
-o They are unlikely to be undetectably used for some other
purpose.
-o Errors can be recovered from by the parser with minimal effort
and minimal possibility of distorting or hiding the intended message.
-o Little typing is needed and esoteric sequences of
special characters do not appear.
______________________________
Character set
No one disagreed when various unacceptable characters were listed.
From this, I take it we should limit the proposal to the set
% & * ( ) _ + - = : ; ' < > ? , . / (space) (tab)
From which we probably should remove some commonly used characters like
. ? , ( ) : ; (space) (tab)
Leaving:
% & * _ + - = ' < > /
(Some of the removed characters could also be used for line markup at
the beginnning of lines.)
The valid characters do include * _ and >, the characters
most often used in markups. But they do not include the caret as used
to point into the line above.
______________________________
Functionality
What functionality must the scheme provide? What additional
functionality is easy to do? What might be nice, but is dispensable?
We need to argue about these categories, keeping in mind the
sentiments for starting with only a minimal set.
*For* *myself* I would categorize the proposed functionalities thusly:
Mimimal required set
-o In-line word marking for emphasis.
At least two forms are needed, based on the
traditional provision of both bold and italic.
-o Quoted lines. From prior messages.
-o Smileys ;-}
Nice, and also easy to include without conflicting intended text
-o Indentation of paragraphs.
-o Bulleted and labeled paragraphs.
May be useful, but seem to make the standard less robust
-o Literal line.
-o Highlighting (commonly done with carets on the next line).
This is problematic with proportional fonts and with filling;
some form of in-line word marking may be possible.
- Literal in-line text. Becomes necessary if the other
conventions are likely to be written without intending their
meaning under these conventions.
- Tabular material. Could be done by interpreting tabs.
Could be done by defining a "fixed width" markup.
Things I could do without <(not that I wouldn't use them:-)>
-o Parenthetic remarks (footnotes).
-o Unfilled, markedup lines.
-o Titled section.
-o Fixed width text.
(Note a subtle problem, above. I used one of the proposed conventions
for footnotes for the joke of using something I was about to say I
could do without. But the smiley entered to highlight the joke is
partially composed from the parenthesis in the footnote markup. If
converted to a footnote, the smiley would lose its grin:-)
One possible result of the simplemail discussion is to obviate the
most pressing needs for MIME (!). We could come up with a set of
conventions that--like smileys, *stars*, and '>' quoted
messages--would be created by many and understood readily by most, all
without the services of modern user agents. User agents could then
capitalize on these possibilities to make such messages more amenable
to those with the hardware/software to read them.
Fred Hansen
Andrew Consortium, Carnegie Mellon
(412) 268-6788 wjh+(_at_)andrew(_dot_)cmu(_dot_)edu