[MIME4J-160] Document/describe how QuotedPrintable/Base64 decoding deal with unexpected input sequences and if we need multiple behaviour supports or not.

• Type: Task
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: 0.6
• Fix Version/s: 0.8.0
• Assignee: Unassigned
• Reporter: Stefano Bagnara
• Created: 03/Jan/10 15:40
• Updated: 22/Apr/13 17:11

Description

Base64 should "die" on unexpected content, but MIME says that any char outside the "charset" should be ignored, because at least CR and LF are expected to appear in mime base64 streams. Should a strict base64 decoder die on some other char or not?

QuotedPrintable currently handle these 2 malformations:
== translated to =
=XX on invalid XX is left as is (=XX)

Some other decoder have different strategies:
some of them match =[hex]?[hex]? some of them match =[any][any] (see how this alter the interpretation of a =X=A=BB sequence)
after matching the treat invalid sequences differently, too. Some of them output the invalid sequence as is, some of them output it without the "=", some other remove the whole sequence from the stream.

The same applies with dealing with space at the end of a line: some implementation leave it as is, some other implementation removes it.

I tried searching the RFC to understand if there is a preferred strategy to deal with malformed sequences but I had no success, maybe I've missed something. Any opinion?

As I know that we rewrote the QuotedPrintableInputStream multiple times, I'd like to head opinions about dealing with malformations.