From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nic Ferrier Newsgroups: gmane.emacs.devel Subject: Re: base64 behavior is not MIME compliant Date: Tue, 05 Jul 2005 23:10:33 +0100 Message-ID: <87wto4j44m.fsf@kanga.tapsellferrier.co.uk> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1120602942 19500 80.91.229.2 (5 Jul 2005 22:35:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 5 Jul 2005 22:35:42 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, bugs@gnus.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 06 00:35:41 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dpw0s-0000tO-C3 for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2005 00:35:34 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dpw29-0007h3-3R for ged-emacs-devel@m.gmane.org; Tue, 05 Jul 2005 18:36:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dpvz7-0006kD-Rm for emacs-devel@gnu.org; Tue, 05 Jul 2005 18:33:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dpvyz-0006g4-P3 for emacs-devel@gnu.org; Tue, 05 Jul 2005 18:33:38 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dpvyy-0006X9-M4 for emacs-devel@gnu.org; Tue, 05 Jul 2005 18:33:36 -0400 Original-Received: from [80.168.156.78] (helo=owls-tree.tapsellferrier.co.uk) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1DpvqX-0004aj-I1; Tue, 05 Jul 2005 18:24:53 -0400 Original-Received: from [80.168.156.68] (helo=kanga) by owls-tree.tapsellferrier.co.uk with esmtp (Exim 4.50 #1 (Debian)) id 1DpvcH-0006WR-Fv; Tue, 05 Jul 2005 23:10:09 +0100 Original-Received: from nferrier by kanga with local (Exim 4.50) id 1Dpvcg-0001z6-CJ; Tue, 05 Jul 2005 23:10:34 +0100 Original-To: Marc Horowitz In-Reply-To: (Marc Horowitz's message of "Tue, 05 Jul 2005 17:35:48 -0400") 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:40471 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:40471 Marc Horowitz writes: > "Richard M. Stallman" writes: > >>> I received a piece of email which passed through an older MTA. This >>> MTA inserted a ! and a newline after every 1000 characters of a very >>> long line of base64-encoded data, which used to be common behavior. >>> When Gnus tried to display this email, it failed, because the ! >>> characters were not recognized as valid base64 encoding. >> >>> Maybe I misunderstood what you were asking for. I thought you >>> were asking us to make additional base64-decode-region signal >>> errors in cases where currently it does not. But now it looks >>> like you are asking for it to accept input that now gives >>> an error. > > I'm sorry I was confusing. To quote my earlier email: > > I believe the best fix is for base64-decode-region to take an optional > argument which specifies how liberal it should be about it's input, > defaulting to the current behavior, and for Gnus to use this argument. > > Defaulting to the current behavior should certainly not mean > signalling errors in new cases. You are correct that I'm asking for a > behavior variant which would result in more input being accepted. If > this variant became the default, I would not object, but I would > certainly understand if you did not want to change the default > behavior. > >>> Could you give a self-contained description of the change that you are >>> requesting in the behavior of this function? > > For the purposes of reading mail, it is valuable to ignore all > characters not part of the base64 character set when decoding. So, my > minimum proposal would be for base64-decode-region to ignore all > unknown characters, instead of signalling errors in this case. > > It would be more generally useful to provide three forms of the > base64-decode-region function, either by having three functions, or > one with an optional argument: > > Form 1: all characters not part of the base64 character set would > be ignored. > > Form 2: any character not part of the base64 character set would > cause an error to be signalled. > > Form 3: any character not part of the union of the base64 > character set and the whitespace characters would cause an error > to be signalled. > > Form 3 is the current observed behavior. I believe there is a need > for Form 1, to make mail reading work more smoothly. Form 2 mainly > exists for completeness. Why can't you just pre-parse the data parsed to the base64 decoder? I believe that's the correct behaviour. A base64 decoder should decode base64, not "base64 but also it does this extra trick if you wave your hand in the air" Nic