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

[[e-mail]]

< From: [e-mail] (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: [e-mail] (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
decode.c:

    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
			  [e-mail], [e-mail]
		    http://ourworld.compuserve.com/homepages/Tony_Hansen