[Top] [All Lists]

Re: questions on QP, non-text attachments and munpack

1996-02-09 16:16:30
< From: jwz(_at_)netscape(_dot_)com (Jamie Zawinski)
<< o   Is my mailer correct in believing that it should be able to use QP
<< for non-text attachments? After all, QP IS supposed to just be an
<< encoding.
<< o   Is munpack wrong in stripping CR's when dealing with non-text
<< attachments?
< I believe the answers are "no" and "yes".  It's true that QP is "just" an
< encoding, but it's an encoding for line-based data, which implies that the
< data should be CRLF while on the wire, but may be converted to the local
< newline convention when decoded.  Base64 doesn't include this implication.
< So for non-line-based data, you need to use Base64.

Show me where in the RFC it says QP is strictly for line-based data. I can't
find anything that implies that.


< From: NED(_at_)INNOSOFT(_dot_)COM (Ned Freed)
< ...
<<     o   Is munpack wrong in stripping CR's when dealing with non-text
<<         attachments?
< It depends on what CRs you are referring to. There are three sorts in QP:
< (1) Those that appear as =0D. These should only appear in the content of
< types other than text -- the rules for text require that CR only be used a
< part of a CRLF sequence and that such sequences be represented as a line
< break in the encoded output. When they do appear in non-text material,
< however, they must not be stripped.
< (2) Those that appear as part of a =<CR><LF> sequence. These "soft breaks"
< should always be removed regardless of the type of content involved.
< (3) Those that appear as a <CR><LF> sequence that isn't preceeded by =.
< These "hard breaks" are only supposed to be used in MIME text. They should
< not appear in non-text material. When they appear in text material,
< however, they must not be discarded.
< My guess is that the case you're referring to is (3), and you did say that
< the material isn't textual in form. In this case there aren't supposed to
< be any hard breaks present. And if there are MUNPACK could strip them if
< it wanted to. It is neither "correct" or "incorrect" to do so.

Unfortunately, I'm referring to (1). Here's a snippet of code from mpack's

    fromqp(inpart, outfile, digestp)
        while ((c1 = part_getc(inpart)) != EOF) {
            if (c1 == '=') {
                c1 = part_getc(inpart);
                if (c1 != '\n') {
                    c1 = HEXCHAR(c1);
                    c2 = part_getc(inpart);
                    c2 = HEXCHAR(c2);
                    c = c1<<4 | c2;
                    if (c != '\r') putc(c, outfile);
                    if (digestp) MD5Update(&context, &c, 1);

Note that it decodes the =XX and then checks it for being a CR.

The comparable line in the from64() routine has this instead:

        if (!suppressCR || buf[0] != '\r') putc(buf[0], outfile);

so obviously it's passed a flag that indicates that it should not suppress
CR's under certain circumstances, presumably for non-text body parts.

From your statements above, you believe that munpack is incorrect.

What sayest the rest of the gang?

                                        Tony Hansen