Please copy me on any issues you see with Microsoft's
support of MIME or any aspect of Internet Mail, and I will
make sure that these issues get handled correctly. I
apologize if you have been frustrated by many people
asking the same question on this topic.
I appreciate the pointer, and I will try to cc you on any issues that arise in
this area.
Ned, I believe that your take on QP line wrapping is never
use the line wrapping for text/plain message bodies on
outbound messages, but do so for attachments right?
Sort of. Whether or not to do QP encoding (it's best not to call it line
wrapping as this confuses its function with its form) is is a function of what
transport you are using and only that. It is not a function of what
presentation you expect or want.
If, for example, you are using HTTP as your transport, it is downright silly to
ever use QP or BASE64 since the transport is capable of handling raw binary.
Just use binary and be done with it.
If you're going out over old-style 7bit SMTP you'd pick QP or BASE64 for sure
if there's any 8bit content or the content isn't textual in form or has lines >
998 characters in length. If the content is short lines of 7bit text you'd have
the option of using QP or BASE64 if you don't trust the transport to deliver
things intact, but otherwise there is no requirement that you use anything
other than 7bit.
Note that the concept of attachments isn't something MIME recognizes as part of
message structure. The attachment/inline distinction is drawn by the
content-disposition header (RFC1806).
Therefore when a UA generates long lines with extended
characters in a message. Lets say the length of the line
is 87 characters, and you do not support text/enriched.
You should use option b) below.
SMTP is supposed to guarantee you 1000 character lines. Lines longer than 1000
characters have to be encoded with either QP or BASE64, but an 87 character
line should be fine. However, this presumes that you really want the line
to be 87 characters long when it is displayed. If you want it wrapped when
it is displayed you should wrap it before you encode it and send it out.
a) Use QP and therefore wrap lines using the QP method
b) Use QP and hard wrap lines at <= 76 characters
You still seem to be confusing QP encoding with presentation.
The problem with option a is that it could force the
unwrapping at the receiving end, and subsequently could
require re-wrapping for UAs not capable of presenting
lines longer than say 80 chars for sake of a better
example
The problem we originally saw with option b is that jagged
lines get presented to the recipient
Sounds to me like your hard wrapping option wasn't implemented properly.
If you know something is a wrappable entity you can do all sorts of
things to make it display better on a fixed width display.
For option b we also considered the following issue when
we did the QP style line wrapping -
A UA generates a message, with extended characters, and
all lines were <= to 76 characters long, therefore the QP
encoding for long lines was not an issue. When the
recipient replies to the message, they prefixed a "> "
combination on the lines, therefore taking some of the
line lengths over 76 characters. Now the reply is sent
with a jagged line.
This is part of the reason why you need to wrap before you encode.
We are considering hard wrapping at <= 76 characters even
if QP is used for the moment, but really would like your
feedback on the right thing to do. i.e. is jagged lines
something you believe is acceptable in Internet Mail for
these cases?
Right. This is the approach you need to use by default.
We are looking at using a lower limit for the wrapping
than 76, and using an upper threshold to decide when to
wrap. Have you used heard of people doing this, and what
upper threshold did they use. We would use the lower limit
to deal with cases where replies to mail originated in our
systems, could be replied to and we could respond back
without forcing jagged lines for those messages atleast,
but this reasoning is still being thought through.
When I think about it I use a threshold of 80 and wrap at 76. This lets someone
put "> " in front and not have stuff fall off the edge.
RE: Text/Enriched (I am investigating what supporting that
means right now by the way, but I am concerned with the
interoperability cases since not every MIME aware
application may have implemented downgrading to text/plain
if they don't support text/enriched.)
Generating text/enriched that looks good on a non-MIME UA *and* works
correctly when viewed on a MIME UA that supports enriched is a nice
clean approach. The downside is that this is a very difficult thing
to get right.
Ned