Here's a mega-reply to the comments thus far (I've been stressed for
time lately):
Excerpts from ext.ietf-822: 13-Apr-93 Re: simplemail draft RFC av..
Nathaniel Borenstein(_at_)thu (3933*)
Given the fluidity of the situation, however, I've concluded that I
should publish the text/enriched draft as an Experimental RFC rather
than a Proposed Standard RFC. I'd encourage Bill & Evan to do the same
with simplemail, but that's their decision.
Sounds like a good idea to me.
As a final metacomment, my perception -- not having tried to implement
it yet -- is that a minimal text/simplemail interpreter will be a little
more complex than a minimal text/enriched interpreter.
Well, of course the simplest simplemail interpreter is no interpreter at
all. A slightly more sophisticated one might do line folding and strip
COLON SOMETHING off the beginning of lines. And so forth.
-- Section 3.2.3 makes reference to sections 4.5.1 and 4.6. Those
sections don't exist. In fact, section 4 is very short, and there's no
section 5. This seems a tad strange, but the page numbers don't
indicate any missing pages... (Note that all my comments refer to the
postscript version.)
Oops. My mistake.
-- You've avoided the issue of non-ASCII character sets. I think this
is important, but the issues are complex, especially for multibyte
character sets.
Yes. My thinking is to let other pioneers take the arrows in the back
for a bit, and profit from their experience.
-- By the way, I commend you on the general formatting of your
postscript version -- it was a pleasure to read, and a good argument for
the value of formatted RFC's.
Thanks. It was done by Evan with FrameMaker. One point to note is that
producing the raw text version took an inordinate amount of hand
editing, from the raw text that Maker puts out. Because of this, and
the likely errors that crept in with hand-editing, I think of the
Postscript version as the definitive text. Doing it with Andrew would
have been much simpler (and probably more accurate for the text version).
-- I was disappointed by the content of section 3.7.2 ("External
References") because I was hoping it was going to give a method for
referencing other MIME body parts that might be inside the same MIME
message as the text/simplemail body part.
Yes, this should be there.
Excerpts from ext.ietf-822: 14-Apr-93 Re: simplemail draft RFC av..
rhys(_at_)cs(_dot_)uq(_dot_)oz(_dot_)au (1149)
First off, congrats to the simplemail people. You've almost convinced me
to switch camps from text/enriched. :-)
Almost!?! Well, simplemail is for a different purpose, so that's
appropriate. I have some notions about how to add the enriched
functionality to simplemail... more on that later.
Thanks. Good points on the suggested ":--" syntax.
Excerpts from ext.ietf-822: 14-Apr-93 Re: simplemail draft RFC av..
Guido(_dot_)van(_dot_)Rossum(_at_)cwi(_dot_)nl (1005*)
I like the simplemail proposal. *Kudos!*
Thanks.
I also would like to see a
more formal syntax specified -- this will make it clear what's legal
and what's borderline or beyond. Things like "it would be nice if the
Yes, I've been putting together a more formal syntax, but I'm a bit
stressed for time just now.
One suggestion: lines starting with "colon space" (instead of "colon
somechar space") currently don't have a defined meaning. We could
Originally, COLON SPACE meant the same as COLON U SPACE, but it seemed a
bad idea to have the parser have to handle this special case, not to
mention fighting over which of the types of unfilled lines deserved the
special case :-). I wouldn't mind using COLON SPACE for literal
quotations.
BTW, one variant of emphasis currently used on the net places
underscores between words, like this: _these_words_are_all_italics._
Can this be supported?
I think you mean, _these_words_are_all_in_an_alternate_vocabulary_... :-).
We had this in at one point, but threw it out because it would imply
*these*words*are*all*emphasized*. It seems to make parsing harder, as
now you have to somehow figure out if, inside an alternate vocabulary
phrase, an underscore means to end the markup, or is just a wierd sort
of whitespace. I still think allowing this stuff is a bad idea.
Excerpts from ext.ietf-822: 14-Apr-93 Re: simplemail draft RFC av..
Nathaniel Borenstein(_at_)thu (651*)
...and if we're talking about supporting existing practices, perhaps we
should think about codifying t_h_i_n_g_s l_i_k_e_ t_h_i_s_.
We are not trying to support bad existing practices, just to promote a
literate mail style that is still readable for people with simple mail
readers. In particular, the above is an example of the problems
inherent in procedural markup when systems change.
Bill