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: Wed, 06 Jul 2005 02:48:23 +0100 Message-ID: <87pstwiu1k.fsf@kanga.tapsellferrier.co.uk> References: <87wto4j44m.fsf@kanga.tapsellferrier.co.uk> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1120615014 11101 80.91.229.2 (6 Jul 2005 01:56:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Jul 2005 01:56:54 +0000 (UTC) Cc: Marc Horowitz , rms@gnu.org, bugs@gnus.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 06 03:56:52 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dpz9M-0006dR-HA for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2005 03:56:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DpzAe-0004CH-9L for ged-emacs-devel@m.gmane.org; Tue, 05 Jul 2005 21:57:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DpzAG-00047j-5O for emacs-devel@gnu.org; Tue, 05 Jul 2005 21:57:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DpzAC-00045s-BT for emacs-devel@gnu.org; Tue, 05 Jul 2005 21:57:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DpzAB-00044B-PR for emacs-devel@gnu.org; Tue, 05 Jul 2005 21:57:23 -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 1Dpz7f-00013l-VD; Tue, 05 Jul 2005 21:54:48 -0400 Original-Received: from [80.168.156.68] (helo=kanga) by owls-tree.tapsellferrier.co.uk with esmtp (Exim 4.50 #1 (Debian)) id 1Dpz15-0006oi-BS; Wed, 06 Jul 2005 02:47:59 +0100 Original-Received: from nferrier by kanga with local (Exim 4.50) id 1Dpz1U-0002ZO-0T; Wed, 06 Jul 2005 02:48:24 +0100 Original-To: Ken Raeburn In-Reply-To: (Ken Raeburn's message of "Tue, 5 Jul 2005 21:15:04 -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:40485 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:40485 Ken Raeburn writes: > On Jul 5, 2005, at 18:10, Nic Ferrier wrote: >> 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" > > Except "this extra trick" is specifically outlined as an option in the > base64 spec (RFC 3548), and MIME invokes that option. So proper "MIME > base64 decoding" would require this extra step of throwing away > characters that are not part of a base64 encoding, and then making a > second pass with the strict base64 decoder. In fact, as I read RFC > 3548 section 2.3, the CR/LF line break sequences in MIME messages are > not part of the base64 alphabet, and therefore > fns.c:IS_BASE64_IGNORABLE already implements a limited form of what > Marc is asking for. You're quite right - my view of what a base64 decoder should do is based on previous implementation rather than what the spec says (mea culpa). Anyway - 2045 (the last MIME/base64 spec I was aware of) says this: The encoded output stream must be represented in lines of no more than 76 characters each. All line breaks or other characters not found in Table 1 [the acceptable alphabet table] must be ignored by decoding software. In base64 data, characters other than those in Table 1, line breaks, and other white space probably indicate a transmission error, about which a warning message or even a message rejection might be appropriate under some circumstances. So this spec suggests that the base64 decoder should optionally error or throw an exception or call a supplied handler or something. How about I write some advice to just throw unwanted characters away for base64-decode-xx? Different advice could be maybe be used when errors are needed. I'm happy to do this if someone wants it - advice is fairly easy to include in stuff without it necessarily being in Emacs. I'll do it on my train journey to work tommorow morning. Nic