Besides UA's and MTA's, there are also e-mail access libraries which form a
common core that is used by both, and allows the authors of UA's and MTA's to
worry about being a UA or an MTA rather than worry about the nitty-gritty
details of how one parses an RFC-822/XXXX message or how one manipulates a
message file/mailbox folder/what-have-you or how one interlocks against
multiple simultaneous access.
I have written such a library.
The problem with things like optional headers for Content-mumble is that I
have to know what all the various headers are and what all their fields mean.
That is, for better of worse I pass on all the information in the useful
headers and ignore the `favorite beer' headers. If everything that is
optional is in a new Content-mumble header, then that requires inventing a new
mechanism to handle everything that begins with `Content-' even if it is a
`Content-Favorite-Beer'.
`Favorite-Beer' sorts of things tend to appear as header names, not in the
bowels otherwise-ordinary message-header data.
I would really rather not play catch-up to have to add a new header line
parser every time some small option is added.
Why, you may ask, don't I pass the RFC-822 header as an abstract object? The
answer is, because RFC-822 isn't the only thing this access library does. So,
I end up with a representation that may be RFC-822 influenced, but is not in
itself RFC-822.
All you've been able to offer for objections is the possibility of bad
software in the future. My case is that software that exists now has problems
with RFC-XXXX as it is presently constituted.
Finally, I feel that making the `attribute=' portion of a parameter optional
for required parameters is a mistake. That will make the BNF and parsing more
complicated. It also suggests that interpretation of paramters is by some
magic order (such as MULTIPART used to be). I would prefer to make *no*
paramters mandatory, which implied implies some clear rules for defaulting.
If you should see:
Content-Type: MULTIPART
then what is the cookie? That's a good question, but there may be an answer
for that that might even make some fans of earlier syntax happy...