ietf-822
[Top] [All Lists]

Re: simplemail

1993-02-11 14:26:33
I really like the idea of a very simple way to do slightly marked-up
text in mail (and news), and the first cut seems well thought out.  I
especially like the way that it is so easy to type and read on a
non-compliant reader.

If such a thing is going to be defined, I'd like to throw in my two
cents:

I like the distinction between *emphasized text* and _alternate
vocabulary use_ (often _Titles_ as well).  I think that this is much
better than forcing the writer to choose bold or italics.  One thing
that has to be decided is how to deal with multi-word phrases that are
so marked.  Three systems seem workable.

        o  As above, with the phrase delimited by a word starting with
           the character and a word ending with the character.  This
           seems to be the scheme proposed by Bill.  The main problem
           here is deciding when to stop if the terminating character
           is missing (either through a typo or a partial quotation).
           If we choose this scheme, we should probably say that the
           markup is terminated by a paragraph break at the latest.

        o  Require delimiters around each character:  *emphasized*
           *text*, _alternate_ _vocabulary_ _use_.  This looks a
           little funny on readers not equipped to show the markup and
           is a little harder to type.

        o  Require the delimiter *between* each word as well as at the
           beginning and end:  *emphasized*text*,
           _alternate_character_set_.  This is how titles are often
           done in messages today.

If the third form is adopted, the second is naturally also
permissible.  This is what I'd recommend.

There should be a way to include a code fragment which may have
special characters in it.  I like the notion of `literal string` for
such strings, with perhaps the normal C notion of \` for embedded
backquotes.  Readers might want to set such strings in a fixed-width
font.

I actually like the notion of footnotes.  Many articles on usenet have
them today, and they usually look something like this.*  The actual
text of the footnote is given as a separate paragraph after the one
that contains it.  I think that this is probably the appropriate way
for a simple reader to display them.  For composing, it would be nice
to be able to type them inline [ like this. ] and have the reader move
them and keep track of numbering or asterisks.  To accommodate
Scandanavian languages, we should probably choose a different way to
mark them. 

*Here's the text of the footnote for the preceding paragraph.  When it
 is longer than a single line, it should be indented like this.

While I think we should stay away from generalized markup, one form
that does occur often in mail and news is the bulleted list like the
one above.  This can be recognized by a new paragraph (signified by
the preceding blank line) starting with white space, the letter "o"*
and some number (probably two or more) blanks.  This would be set as
above, with the whole paragraph indented (as with a quotation) and
with a hanging first indent of some bullet character.  I don't think
that there is any real need to have other kinds of lists, or lists
within lists, but these could be defined as well.

*To forestall problems with languages in which "o" is a reasonable
 word, perhaps another character (maybe "." or "-") should be chosen.

One potentially complicated thing I think we have to get right for
this to be of any real use is embedded quoting of messages.  Some
things to keep in mind:

        o  It must be possible to quote messages that are not
           simplemail compliant.  When replying to such messages, the
           editor should prefix each line with "> ," to mark it as
           literal. 

        o  It must be possible to correctly display messages which
           quote messages that *are* simplemail compliant.  This means
           that if we use a prefix string such as "> " to signal the
           quote, we must strip it off when looking for paragraphs,
           literal quotes, bulleted lists, etc.  The same goes for
           quotes within quotes, etc.

        o  It must be possible to quote to an arbitrary amount of
           nesting.  Readers should provide some signal to the user of
           the current nesting level.  I don't think that mere
           indentation is sufficient.

        o  It is often useful to be able to compare two (or more)
           items.  This is usually done by chosing a different prefix
           character for each.  Perhaps we should allow more than one
           acceptable quote prefix.  Good choices might be "> ", "] ",
           "~ ", etc.  Characters chosen as bullets should not be
           used here to be able to distinguish quoted bullet items
           from double quoting.

        o  One feature that is often used is the ability to point out
           and comment on individual words in a quotation, like this

           > Here I talk about some potentially controversial word
                                    ^^^^^^^^^^^
           "Potentially"?!  Are you out of your mind?
           > which some people might take exception to.

           This is already a problem for people with readers that
           display text in proportional-spaced fonts; it will be more
           of one when the readers do their own line breaking as well.
           This is a very useful construct, and this (or something
           similar) is probably a good way to display it, but I'm not
           sure how you go about recognizing what is being pointed at
           in the general case.

Finally, while I don't think that we should get into the whole notion
of font size, it would be very useful in some domains to have a simple
way to say superscript and subscript.  My own first cut would be to
recognize delimited TeX sequences such as a_{i} = a_{i-1}^{2}.

Evan Kirshenbaum                       +------------------------------------
    HP Laboratories                    | C: I'd like to take a few of you back
    3500 Deer Creek Road, Building 26U |    with me.  To prove I discovered
    Palo Alto, CA  94304               |    you.
                                       | I: What you mean, discover us?  We
    kirshenbaum(_at_)hpl(_dot_)hp(_dot_)com            |    discover you.  We 
discover you on
    (415)857-7572                      |    beach here.  Is all how you look
                                       |    at it.

<Prev in Thread] Current Thread [Next in Thread>
  • Re: simplemail, Evan Kirshenbaum <=