On Thu, 09 Jun 2011 16:45:08 +0900, "Stephen J. Turnbull" <step...@xemacs.org> wrote: > 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. :)
Ah, right. Which means we don't support that currently... > > 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. Well, the main motivation was so that I could change the semantics of __setitem__. > > > * 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. Well, that's already in place. The parser treats duplicate unique headers as a defect by default. But there needs to be a way to construct invalid messages, too, I think. Heh. And I forgot, there actually is a way with the current code to create duplicate headers, you just have to call append instead of using __setitem__. So maybe it wouldn't be totally crazy to have unique headers __setitem__ be replace while non-unique headers __setitem__ does append. We could even go really crazy and have Resent headers __setitem__ do prepend :) The other way to control this "unique header" behavior would be to change the header registry. If you are building an application whose headers do not conform to the RFC, you would probably end up doing that anyway. If you combine the last two ideas, we could have a carefully defined API for controlling how __setitem__ works using attributes on the header classes. Totally crazy? Crazy-smart? > > > 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. Are you saying = should append to the value? I think that would be bad/counterintuitive. > > But += isn't and I want to support that, as you note later. > > +1 for += (and perhaps -=). Agreed. > > > 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. How about a validate function that takes a message and a policy? That would be parallel to generator. In fact, it might share some code with generator. -- R. David Murray http://www.bitdance.com _______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
