[Email-SIG] API for Header objects [was: Dropping bytes "support" in json]

[Tony Nelson]

At 03:38 +0900 04/14/2009, Stephen J. Turnbull wrote:
>Tony Nelson writes:
>
> > OK, Header instances could have a .useful field that returned the useful
> > data in all instances.  But in any case, the email package should guide
> > users in the correct usage, rather than leaving every choice seeming equal,
> > when only one choice is correct.
>
>What do you mean by "only one choice is correct?"  For example, a
>Destination field might be used for presentation (in which case the
>display name are needed), or to compose a list of recipients (when
>thjey should be discarded).  Some applications might prefer to receive
>the combination as the original string (although that often is not
>valid RFC-any), others might prefer it parsed into a pair of display
>name and mailbox.
 ...

Assuming that by "Destination" you mean a class of Address header fields,
as there is no Destionation: header field, such header fields contain
addresses, which can be considered to contain (as the email package does) a
list of (name, email address) pairs, or, at a lower level, to also have
Comments, there is indeed only one correct choice, which is the one the
email package currently provides the diligent user.  I wish it to be the
one obvious choice, so that less study is needed to properly use the email
package.

Any use that wishes to discard the email addresses in favor of the friendly
names can do so most easily from the parsed [(name, address)], not from the
bytes.  Parsing Address header fields is hard.  Note that Address headers
are not Text, as only certain tokens -- not part of the email addresses --
can be RFC 2047-encoded.
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>