Comment 60 for bug 369150

I don't think decoding is a real problem, but parsing on compose is.
We can't simply keep encoded words, copy them around and only decode them for display. When answering we get at the same point as when composing from scratch: The user wants to add, remove, modify names and addresses. And after that step everything has to be parsed and encoded.
For this we've to deal with for example the following input:
Björnsen, Jörn <email address hidden>
Jörn Björnsen <email address hidden>
"Björnsen, Jörn" <email address hidden>
"Jörn Björnsen" <email address hidden>
Jörn "King" Björnsen <email address hidden>

It doesn't matter if this comes from a mail that is being replied to or from user input for a newly composed one.

RFC2047-encoding each of the first four display names is valid with those quotes or with them removed. Quotes in the last one should be keept and encoded in any case—and without quoting it by prepending a \.

Remark: Though the compose window offers several lines but it's not only not restricted to one address per line, the whole bunch of addresses is carried comma-separated in one single char * string through a dozend functions.

So parsing is hard and currently we fail in the first example to get that as one address. To ease that part, I'd like to put quotes around names that contain commas if we know that's just one name. Extracting
=?ISO-8859-1?Q?Bj=F6rnsen=2C_J=F6rn?= ...
from a mail is such a situation.
Quotes wrapped around the name automatically as well as by the user should be removed again before 2047-encoding. As a problem I see user entered addresses like
"Jörn "God" Bjönsen" <email address hidden>
which should 2822-correctly be
"Jörn \"God\" Bjönsen"
and 2047-encoded
=?ISO-8859-1?Q?J=F6rn_=22God=22_Bj=F6rnsen?=

I'd like to hear some thoughts on that.