< 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
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
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
http://ourworld.compuserve.com/homepages/Tony_Hansen