Re: Sending attachments

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

Richard Stallman writes:

 > Someone asked me why I see this as a problem, and I explained why.
 > You may not see it as a problem, but the point is that I do.

Sure.  And my point is that I don't understand why you see it as a
problem.  I like to understand these things, and I'm at a loss to come
up with a sane rationalization.  So I feel very very stuck.  That
would be OK if it were just me, but I don't think I'm the only one who
feels that way.  In fact I think some of those who are feeling stuck
are important contributors to Emacs, and to free software.

 >     It seems to me that both Gnus and Emacs would benefit from you
 >     pow-wowing with Miles Bader and anybody else who works on Gnus-Emacs
 >     integration, and make the points about refactoring and maintainability
 >     to them.
 > 
 > I would like to see progress in this direction, and I am willing to do
 > a certain amount of work to help it.  However, at present I have
 > nothing to specific suggest, because I know very little about the code
 > of Gnus.

What you've posted about rfc2047.el already goes way beyond
"nothing". :-)

 > Its complexity has discouraged me from looking at it except in
 > cases of need.

Unfortunately, that complexity is mostly a reflection of the problem
domain.  It is *not* merely a reflection of the number of features of
Gnus; reducing the complexity of your requirements will not reduce the
complexity of a RFC conforming implementation proportionately.  For
example, you personally may have no need to send non-ASCII characters
in headers.  Nevertheless, the MUA you use must check for them,
because they might be present in an automatically generated header
(eg, a reply).  Of course you can simplify somewhat by refusing to
implement RFC 2047, and simply have `mail-send' signal an error,
leaving it to the user to clean up the header.  But the check itself
is complexity, and goes beyond what Mail mode has ever done.  And it
gets worse; RFC 2047 by itself is insufficient.  Even if you've
implemented RFC 2047, you need to check whether parameter values of
MIME headers contain non-ASCII, because RFC 2047 itself specifically
prohibits use of RFC 2047 encoded-words in parameters.  Now, you also
need RFC 2231.  Mail is rife with these corner cases.

This is not mere conformance for the sake of conformance.  To give one
example, Mailman for many years had a bug where a non-ASCII character
in a header could cause a whole installation and all of its lists to
become unusable until a sysadmin shunts the offending message out of
the queue.

 > If Gnus developers are interested in doing work to make these files
 > modular, I'm interested in looking for candidates.

Thank you!