I've read over the draft, and naturally I have lots of comments.
The first metacomment, which shouldn't surprise Bill or Evan but may
surprise other folks, is that I LOVE this proposal and don't at all mind
the "competition" with text/enriched. I'm not really sure that I
percieve them as 100% competitive anyway in that there may be a role for
both (for example, simplemail is easier to generate by hand, but
enriched may be easier to generate in the context of existing word
processors). But those of you who've been on this mailing list for a
long time will know that I'm very much in favor of letting a thousand
flowers bloom where possible. I'd like to see good specs published as
RFCs for both text/enriched and text/simplemail, and let the market
decide whether one, both, or neither of these formats meet real needs.
That's why MIME's extensible, after all.
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.
As another metacomment, I sincerely hope that nobody feels the need to
start a "simplemail vs enriched" war. For my part, I don't know if I'm
going to have time to write my own implementation of text/simplemail any
time soon (even text/enriched will be a challenge at this point) but
I'll happily include a good PD text/simplemail interpreter in the
metamail distribution if anyone offers me one.
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. I'd love to be
proven wrong. I have gotten very positive response to the simple
text/enriched interpreter that I provide as an appendix, and I'd
encourage you to try to include something similar.
OK, on to more detailed stuff:
-- At the risk of sounding like Dave Crocker (horrors!), I'd *really*
like to see a formal grammar in this document. (Dave probably passed
out when he read the previous sentence. Either that, or he assumes this
message is a forgery.) I'm *pretty sure* that the specification is
unambiguously parsable, but I'm not positive. A formal grammar would be
reassuring.
-- 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.)
-- 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. I've recently come up with a new idea for how to do
text/enriched with multibyte character sets, which involves making the
metacharacters ("<" and ">" in the case of text/enriched;
text/simplemail has a few more) paramaterizable on the content-type
line. You might want to check this out (I'll be publishing a new
text/enriched spec shortly) and consider a similar approach for
text/simplemail.
-- 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.
-- Section 3.2.3 doesn't tell how to include backquotes in literal text.
(Perhaps this is intended to be explained in the mythical sections
4.5.1 or 4.6, though.)
-- 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. Given the other mechanisms
you've defined, this should be pretty easy to add. How about
<<<content-id>>> as a syntax?
In general, a beautiful document. Great work! -- Nathaniel