Re: base64 encoding in rfc2045...

> (Man.. I was around for rfc1341. You'd think that by now, there'd be
> few things that would give me a "Wait, what?" moment...)

> So over on another list, a discussion arose of what an MUA should do
> if it receives a base64-encoded mail that's been altered. (In this case,
> it's mailing list software that's blindly stuck a "you received this because"
> footer onto a mail that was UTF-8/base64)

> And when I went to go cite chapter and verse, I discovered some text that
> seemed to contradict itself - OK for a religious text. An RFC? Not so much.

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

> I'm having a hard time matching even a lower-case 'must be ignored'
> up against "a warning message.. might be appropriate...". 

I see no conflict. The decoder doesn't let the garbage affect its output but
reporting the presence of garbage is recommended.

> Was the
> intent here "Just keep going, and optionally tell the recipient that everything
> from this point on is pure zorkum-blattum"?

More or less.

> Personally, I'm of the opinion that in reality, encountering a '=' is
> sufficient grounds for stopping right there, and also punting if a null line is
> encountered, because the chances it's a unintended appended text is much higher
> than a properly functioning base64 encoder generating an actual correct null
> line.

The text doesn't address the issue of what to do when an end marker  is
encountered (the marker isn't always present) but there's material after it. 
(Note that the material could consist of only valid base64 characters.)
Absent a recommendation, you are free to handle this case however you
want.

				Ned

_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822