Author r.david.murray
Recipients Red HamsterX, ajaksu2, amaury.forgeotdarc, gvanrossum, pitrou, r.david.murray, sanxiyn
Date 2009-07-29.18:04:56
SpamBayes Score 2.25769e-12
Marked as misclassified No
Message-id <1248890698.05.0.900708657335.issue1466065@psf.upfronthosting.co.za>
In-reply-to
Content
It turns out that the RFC is unambiguous on this point.  Quoting the
base64 section of RFC 2045:

   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 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.

Since "some circumstances" is not something the base64 decoder can
decide, that has to be left to a higher level ap.  So if unexpected
characters are to generate an error, it would need to be enabled via a
flag that defaults to not raising the error, IMO.  Unless someone has a
use case for rejecting an improperly encoded message, we should probably
just fix the docs (perhaps noting that this behavior is in accordance
with the RFC).
History
Date User Action Args
2009-07-29 18:04:58r.david.murraysetrecipients: + r.david.murray, gvanrossum, amaury.forgeotdarc, sanxiyn, pitrou, ajaksu2, Red HamsterX
2009-07-29 18:04:58r.david.murraysetmessageid: <1248890698.05.0.900708657335.issue1466065@psf.upfronthosting.co.za>
2009-07-29 18:04:57r.david.murraylinkissue1466065 messages
2009-07-29 18:04:56r.david.murraycreate