Re: BEGIN_SRC..END_SRC

["Stephen J. Turnbull" <stephen@xemacs.org>]

Yann Hodique writes:
 >>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

 > > Use "Content-Type: text/emacs-lisp" and see what happens.
 > 
 > As I said in a previous mail, it doesn't change anything for GMail, and
 > that is also (unfortunately) conformant.

I disagree.  It may be unfortunate, but it is not conformant.  To
quote the RFCs:

4.1.4.  Unrecognized Subtypes

   Unrecognized subtypes of "text" should be treated as subtype "plain"
   as long as the MIME implementation knows how to handle the charset.
   Unrecognized subtypes which also specify an unrecognized charset
   should be treated as "application/octet-stream". -- RFC 2046

The word "should" in an RFC has a precise (and to many, surprisingly
strong) meaning:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course. -- RFC 2119

So it isn't optional behavior.  It's required.  It's simply the case
that the authors of RFC 2046 could imagine stuff like Microsoft HTML,
in which case you probably want to treat text/html as binary if you
don't have a decent HTML rendering engine to use.  However, "should"
in the section 4.1.4 is not blanket permission to treat all unknown
text/* as application/octet-stream, as Gmail apparently does.

 > Only [Gnus] we can fix. So in any case, I don't believe we can
 > ever afford not to emit the text/plain alternative for dumb (yet
 > potentially even conformant) MUAs.

Maybe.

But given that we know that Gmail deliberately goes out of its way to
suck in our community (eg, encouraging top-posting, which has its
place but it ain't here[1]), I don't really think we should consider
problems with Gmail an argument against using standard constructs.  If
Thunderbird or nmh or mutt has issues or whatever-the-GNOMEish-MUA-is
does, that's another matter.

 > Given that, since Emacs is probably the only "MUA" that will ever
 > implement a handler for any elisp-related MIME type, whether it's
 > text/emacs-lisp or application/emacs-lisp is probably not that much of
 > an issue (but again, we should use the former)

No, it's the *only* issue here.  If we use text/emacs-lisp, people who
use conformant MUAs have a choice of font-locked display or plain
text.  If we use application/emacs-lisp, people who use conformant
MUAs have a choice of font-locked display or saving it to a file.


Footnotes: 
[1]  Tevye: Rabbi, is there a blessing for the Czar?
     Rabbi: Of course, my son.  (sonorously) May God bless and keep
     the Czar ... (with emphasis) far away from us!