From: Nic Ferrier <nferrier@tapsellferrier.co.uk>
Cc: Marc Horowitz <marc@mit.edu>,
rms@gnu.org, bugs@gnus.org, emacs-devel@gnu.org
Subject: Re: base64 behavior is not MIME compliant
Date: Wed, 06 Jul 2005 02:48:23 +0100 [thread overview]
Message-ID: <87pstwiu1k.fsf@kanga.tapsellferrier.co.uk> (raw)
In-Reply-To: <e7023d30307e3db909bb5a25de0a313f@raeburn.org> (Ken Raeburn's message of "Tue, 5 Jul 2005 21:15:04 -0400")
Ken Raeburn <raeburn@raeburn.org> 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
next prev parent reply other threads:[~2005-07-06 1:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-02 23:19 base64 behavior is not MIME compliant Marc Horowitz
2005-07-03 20:43 ` Richard M. Stallman
2005-07-03 21:09 ` Nic Ferrier
2005-07-04 4:59 ` Marc Horowitz
2005-07-05 4:35 ` Richard M. Stallman
2005-07-05 21:35 ` Marc Horowitz
2005-07-05 22:10 ` Nic Ferrier
2005-07-05 23:55 ` Marc Horowitz
2005-07-06 1:06 ` Nic Ferrier
2005-07-06 1:15 ` Ken Raeburn
2005-07-06 1:48 ` Nic Ferrier [this message]
2005-07-05 22:52 ` Arne Jørgensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pstwiu1k.fsf@kanga.tapsellferrier.co.uk \
--to=nferrier@tapsellferrier.co.uk \
--cc=bugs@gnus.org \
--cc=emacs-devel@gnu.org \
--cc=marc@mit.edu \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.