One of my personal 'aims' with 'mail-ng' is for everything to be human
readable unless necessary. So, header fields should be human readable,
binary attachments don't need to be. I've spent a lot of time writing
& debugging implementations of protocols such as SMTP, POP3, IMAP4,
LDAP etc, and the text ones are many times easier to deal with than
the binary ones. (OK, this may be down to the vaguaries of ASN.1, but
that in itself may be encouraged by the binary-ness of it)
One of my metrics is "how many page faults does the programmer have to
take in order to get to the relevant parts of the specification for
whatever he is writing/parsing". A 'page fault' is having to hunt
around in the current specification document, open another document,
click on another link, etc. You should also assume that the programmer
has a fairly small working set, so having to look at lots of different
specifications to see things on different levels (think of ASN.1 and
BER and the ASN.1 specifications for the various data structures used by
the application - which may themselves be in different documents or in
different portions of the same document).
Other things being equal, text formats tend to produce fewer programmer
page faults because the format of the data is often 'obvious', and
because the presentation layer is trivial. One downside is that sometimes
the implementor's assumptions about the format are wrong. Another
downside is that trivial presentation layers are fairly limited - they
have a hard time representing arbitrarily nested structures, for instance.
Seen from this light, I agree that some version of the ISO date format
(one with a numeric timezone offset) would be better than 822/2822
date-time if we were starting from scratch. I'm not sure whether it's
still worth switching to a new date format when considering conversion
issues - versus carefully documenting how to generate and parse 2822
date-times.
--
Regime change 2004 - better late than never.