[Email-SIG] email.header.decode_header eats my spaces

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 28, 2007, at 10:58 PM, Stephen J. Turnbull wrote:

> If you want "unicode(h)" ==> "helloworld", you need to encode the
> whole string.  (Giving 'hello' the charset 'utf-8' would be a hackish
> way of doing this.)

 >>> decode_header('=?us-ascii?q?hello?= =?us-ascii?q?world?=')
[('helloworld', 'us-ascii')]

>> The problem in email.header module is it can not distiguish between
>> the structured and unstructured (text only) headers.
>
> Yikes!  I didn't think of it that way before, but now that you mention
> it, my spine is freezing.

Indeed.

>> The Header class may have a member function like 'add_comment',
>> IMHO.
>
> IMHO, the Header class should be abstract, and there should be
> subclasses that handle dates, lists of addresses, lists of
> message-ids, etc. as appropriate to header fields structured in each
> particular way.  Only those object handlers appropriate to a given
> field would be exposed.  StarTextHeader would the unstructured
> derivative of the (implicitly structured) Header class.

I'm not sure inheritance is the right way to organize this.  I think  
instead you might want an interface that allows you to specify header  
body 'interpreters' which can be associated with Header instances.   
These interpreters would handle things like splitting and folding  
header bodies, handling appending of words, etc.

Or, maybe inheritance is right.  In any case, I think you also want  
to also have a registry of some sort so that something like the  
Parser could find a header subclass or header interpreter to use as  
it was parsing a message text.  You want this so an application could  
register x-headers.

[Steve says lots of other intelligent things that Barry agrees with]

I'm pretty tired right now so the only thing I can add is...

> And the email package needs to be free to deal with structured headers
> appropriately (for example, breaking very long addresses to try to
> keep line-length to a reasonable level).  It may not be feasible to
> respect user preferences in all cases.

...that I want to keep in mind that because of x-headers, we have to  
have an extensible architecture.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRgtG9HEjvBPtnXfVAQKgnQP/dts4njMjpB495yNvokiPBBPbPCSajTfH
hN5eYh5/3RJP6bOg+ABJlt56ya7QWD0J60cYWJJM2USRqDomGsWq24+TZ+5hsfTr
jX87K0qy1vplViyILKbLl1Kfn+hvAQiAPH+57+do+0VX8fQM36QUosy19abaiOod
mv9r8QQ/aBA=
=jwSp
-----END PGP SIGNATURE-----