From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Marc Horowitz Newsgroups: gmane.emacs.devel Subject: Re: base64 behavior is not MIME compliant Date: Tue, 05 Jul 2005 17:35:48 -0400 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1120601344 15505 80.91.229.2 (5 Jul 2005 22:09:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 5 Jul 2005 22:09:04 +0000 (UTC) Cc: bugs@gnus.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 06 00:09:03 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DpvYR-0004wk-Gy for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2005 00:06:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DpvZi-0007RR-Lx for ged-emacs-devel@m.gmane.org; Tue, 05 Jul 2005 18:07:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DpvWd-0006Ee-Ag for emacs-devel@gnu.org; Tue, 05 Jul 2005 18:04:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DpvWc-0006E7-2k for emacs-devel@gnu.org; Tue, 05 Jul 2005 18:04:18 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DpvVY-0005Fz-OC for emacs-devel@gnu.org; Tue, 05 Jul 2005 18:03:12 -0400 Original-Received: from [69.25.196.4] (helo=pulse-plasma-gun.nerd-militia.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DpvBD-0001g0-8p; Tue, 05 Jul 2005 17:42:11 -0400 Original-Received: from ayer.connecterra.net (unknown [4.36.55.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pulse-plasma-gun.nerd-militia.org (Postfix) with ESMTP id AF0D04C503; Tue, 5 Jul 2005 17:35:51 -0400 (EDT) Original-To: rms@gnu.org In-Reply-To: (Richard M. Stallman's message of "Tue, 05 Jul 2005 00:35:56 -0400") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) 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:40468 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:40468 "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. Marc