[Email-SIG] rfc822 parser (the elephant has landed)

[Stephen J. Turnbull]

R. David Murray writes:

 > Yeah, it would be really nice if setting (say) 'To' replaced it, but
 > setting (say) 'Resent-To' appended.  But that way lies chaos :)

Especially since "Resent-To" (and other Resent-*, as well as trace
headers) needs to be *pre*pended. :)

 > One of my ideas is to eventually decouple the header dictionary from the
 > Message.

I don't understand why you want to do that; in many applications, you
pass around a reference to the body but never need to access it until
a final flattening operation.  The headers are naturally structured as
a list or ordered dictionary.  Bodies OTOH are recursively structured,
so they really can't be handled in the same way.

 > > * Unique headers: is this controlled or influenced by a policy?  For example,
 > >   duplicate Subjects might be disallowed by RFC 5322, but could conceivably be
 > >   allowed (or at least not prohibited) by other email-like protocols.
 > 
 > Right now it is always applied, but IMO it needs to be a policy
 > setting.

Yes.  The Postel Principle applies here.

 > >   Also, while some fields like CC allow only occurrence, it can contain
 > >   multiple values in that single field.  Is it totally insane to say that
 > >   `msg['cc'] = 'address'` would append `address` to the existing value?  It
 > >   probably is, but having to do that manually also kind of sucks.
 > 
 > Yeah I think that would be insane :).

+1 for insanity.

 > But += isn't and I want to support that, as you note later.

+1 for += (and perhaps -=).

 > >   Some headers have other constraints (RFC 5322, $3.6).  For example
 > >   Message-ID can technically appear zero times, but "SHOULD be present".  Part
 > >   of me thinks it should be out of scope for email6 to enforce this, and I'm
 > >   not sure where that would get enforced anyway, but I'm just wondering if
 > >   you've thought about that.
 > 
 > That one I think can only be enforced when the message is known to be
 > "complete", which would be when it is transmitted.

"Enforced", yes, it's out of scope, for several reasons.  However, any
given application may know at some early stage that headers are
complete, and want to check policy at that point.  So there should be
a mechanism to explicitly check policy conformance, perhaps a
.check_policy() method on Message objects.  Then it becomes a question
of whether the policy check should ever be called implicitly, or
always left up to the application.