RE: Line Wrapping Question

[Ned Freed <[e-mail]>]

> 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