From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Sending attachments Date: Fri, 10 Jul 2009 21:42:13 +0900 Message-ID: <87my7clnfe.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87k52rzyn1.fsf@benthic.rattlesnake.com> <873a9fw6dt.fsf@catnip.gol.com> <87y6r7yp1y.fsf@stupidchicken.com> <87ljn1dcc4.fsf@stupidchicken.com> <4A5485D0.5060808@gnu.org> <87d48b9trl.fsf@catnip.gol.com> <871vor45w8.fsf@iki.fi> <87y6qz8d1y.fsf@catnip.gol.com> <87eispzixw.fsf@marauder.physik.uni-ulm.de> <87skh4lxln.fsf@uwakimon.sk.tsukuba.ac.jp> <83fxd4yf6l.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1247231163 1733 80.91.229.12 (10 Jul 2009 13:06:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jul 2009 13:06:03 +0000 (UTC) Cc: rms@gnu.org, Reiner.Steib@gmx.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 10 15:05:56 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MPFnW-0001r2-NL for ged-emacs-devel@m.gmane.org; Fri, 10 Jul 2009 15:05:55 +0200 Original-Received: from localhost ([127.0.0.1]:49227 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MPFnW-0001WZ-4e for ged-emacs-devel@m.gmane.org; Fri, 10 Jul 2009 09:05:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MPFSA-0004p8-MU for emacs-devel@gnu.org; Fri, 10 Jul 2009 08:43:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MPFS4-0004gK-0E for emacs-devel@gnu.org; Fri, 10 Jul 2009 08:43:48 -0400 Original-Received: from [199.232.76.173] (port=53306 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MPFS3-0004g7-O2 for emacs-devel@gnu.org; Fri, 10 Jul 2009 08:43:43 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:59491) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MPFRw-0005R9-8d; Fri, 10 Jul 2009 08:43:36 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 317618210; Fri, 10 Jul 2009 21:43:34 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 3FFAC1A3002; Fri, 10 Jul 2009 21:42:13 +0900 (JST) In-Reply-To: <83fxd4yf6l.fsf@gnu.org> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 5bbff3553494 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:112304 Archived-At: Eli Zaretskii writes: > > From: "Stephen J. Turnbull" > > Date: Fri, 10 Jul 2009 18:02:28 +0900 > > Cc: Reiner Steib , emacs-devel@gnu.org > > > > Thing is, that complexity is going to pop up at every turn as you > > develop these features. > > True. Which is why I thought the intent was to create something > exceedingly simple, e.g.: That simplicity drove me nuts as a Mule maintainer, because it didn't try to defend against users who went beyond the parameters sendmail.el was ready to deal with. Eg, I would tell somebody to send a bug report using M-x report-xemacs-bug. That uses sendmail.el because Gnus and VM are both in the package distribution of XEmacs. They'd put non-ASCII in the header because it was a phrase they were having problems getting Mule to handle correctly, Mule would encode it to (raw, not RFC 2047) KOI8 or something, and it would take down the bug list because (at that time) Mailman assumed ASCII in the headers of mail coming off the wire, and threw an exception if it didn't get it. (Now we just get mojibake, but we've fixed our bug reporter to say "if possible we would really appreciate if you would kill this buffer, customize `mail-composition-agent' and start your report over" because really people do want to attach files, sometimes with non-ASCII names, with their reports.) OK, so now you fix mail-mode to deal with this. You have two options: error on non-ASCII in the headers, or RFC 2047 encode. This is non-trivial if you want to be RFC conformant, because you SHOULD use quoted printable encoding for languages like French that use ASCII supersets, and SHOULD use BASE64 for languages like Hebrew that don't. (In practice this is usually done by looking at the fraction of ASCII characters, rather than by determining the language.) See RFC 2119 for the official definitions of requirement levels of capitalized terms like SHOULD and MUST; IMHO a SHOULD is pretty strong. Good, good, we're making progress (at the expense of a couple hundred lines of code unless you grab rfc2047.el from Gnus -- which is what Ken'ichi's 10-line .emacs hook does), whose usage assume several other libraries in the usual Gnus-y way, and is 35KB or so by itself). OK, so now we add an attachment feature. No problem, right? We already handle RFC 2047, so our headers are OK, right? Wrong. RFC 2047 *specifically* forbids use of the encoding it defines to specify file names in MIME headers. This is a MUST NOT; a failure to conform means you have a non-conformant MUA. This is a boolean standard, your MUA flunks, it's not "a little bit non-conformant". OK. so now we have a choice. You can error on an attempt to use a non-ASCII filename, or you can implement RFC 2231. More complexity, rfc2231.el is 10KB. Or you could munge the file name in some way and instruct the recipient to change it back, or ask the sender to change it. Sure, you could stop short of a full implementation of all the RFCs related to these "minimal features" you want, but where? Figuring out what to to include and what not to include, and introducing code to check for and refuse unsupported requests from the user is non-trivial, itself, and IMO should be based on an even better knowledge of the RFCs than simply implementing the whole RFC. You could say, oh, we don't have to do that. And you're right ... but IMO a non-RFC-conforming product really isn't something you want to distribute as part of Emacs. Is it really worth dealing with all this when as far as Miles and I can tell, the sendmail.el UI (including hooks and keyboard macros) is a 100% compatible subset of the Message mode UI? Wouldn't it be a better idea for one of the few serious Mail mode users to just try Message mode for a few days, and fix any problems that show up? Reading the RFCs is not easy. Richard's point about complexity and modularity is a good one, of course, but Message mode isn't that complex and is reasonably well-factored. The complexity comes in on the reader side of Gnus, and I admit that's an impenetrable thicket of code. But then, it's much much easier to write something that just produces conformant messages in RFC 822 format than it is to have a multibackend reader that not only deals with netnews and a host of mail formats, but also the hideous stuff that is produced by Microsoft and Yahoo! mailers, not to mention spammers.