[Email-SIG] Plans for email 6.0

[Stephen J. Turnbull]

Tony Nelson writes:

 > In general, users of the email package must currently be familiar with all
 > the mail RFCs in order to properly use the package to create or manipulate
 > any but the simplest messages,

IMHO, that's a problem with the mail RFCs, not with the email
package.  Internet messaging is inherently complex because of the
backward and Microsoft compatibility requirements.

 > and having "[]" mean "append" isn't helping.

That's probably true, but that's because in Python mapping semantics
are invariably replace rather than append in this circumstance.  It
has nothing to do with the RFCs per se.

 > Your suggestion that header fields should always be represented as
 > Header objects is urgently needed.  Those Header objects will need
 > to be smart about the header field they represent, and apply all
 > the various encodings etc. as necessary.

That's not a good idea.  Header methods should be strict about what
encodings are allowed, but all too often the decisions between
quoted-printable and base64 transfer encodings, and among various
possible text encodings (Japanese alone has 4 majors ones in *daily*
use, with different ones typically used in the header and body! and
Chinese isn't much better) are dependent on content or receiver and/or
sender.

It's reasonable for email to have "recommendations", perhaps
implemented as defaults, for each situation, but programmers should be
reminded that that the text they provide to the Header class etc is
being munged as it gets inserted into the message.  For simple
situations, of course it makes sense to provide a high-level
interface, such as a string:contents dictionary for headers.

headers = { "From" : [("Stephen J. Turnbull", "stephen at xemacs.org")],
            "To" : [("Email SIG", "email-sig at python.org"),
                    ("da FLUFL", "barry at python.org")],
            "Subject" : "Don't DO that!"
            "Summary" : "This could go on forever but doesn't." }

body = """I just wanted you to know that I
don't think it's a good idea.

Just-yer-neighborhood-busybody-ly y'rs
"""

ready_for_sendmail = email.format_simple_message (headers, body)

And that would be encoded in some lowest-common-denominator charset
like ASCII, ISO-8859-15, ISO-8859-1, or UTF-8 with the earliest
feasible one used, and some heuristic like minimum encoded size or
fraction of non-ASCII used to determine content-transfer-encoding.

But it should be implemented by .format_simple_message, not Header,
IMHO.