Folks,
Warning bells are going off, all over my neural net, so let me pass on
the pain:
Most of the Internet protocols have suffered from extreme simplicity.
That deficiency seems to have been a major reason for their success.
The simplicity seems to buy two things: smaller code and easier human
comprehension. From my own experience, the latter is at least as important
as the former.
RFCXXX maintains the basic style of simplicity, with two exceptions:
One is the message-part boundary specification and the other is in
character sets. The boundary line spec is quite unusual and the examples
given make them look complicated, though in fact, very simple strings
also can be used. Hence, that source of complexity does not seem so bad.
The character set issue is the fact that the RFC supports a large number of
them, rather than fixating on just one. Hence, the potential danger of
sending messages in the wrong character set is going to be handed to
users. The reason given for deferring making the choice from just-one
character set is that there doesn't seem to be any clear choice. What we
are left with is exactly the kind of ambiguity (of choice, not of the spec)
that is common in other standards groups. Don't make a choice; specify
support for everything, thereby giving implementors, operators, and users
absolutely no guidance which facilitates interoperability on the global
Internet.
Now, you might notice that the choice DOES support interoperability on a
local scale, where the current Internet standards clearly do not. I hope
that you also will notice that the trade-off between local and global
optimization is at the heart of standards efforts and that the Internet
has consistently chosen to go with ONE canonical spec, rather than
to support arbitrary combinatorials.
I decided not to pursue this point, about RFCXXX, because I think that
it might not have quite the horrible impact that I fear. But the
current lines of discussion for the header are quite another matter.
We have proposals that alter basic styles of doing business (e.g., adding
cross-correlation of headers or even making header be order-dependent)
and other that simply will render them unreadable.
All of this cleverness in everyone's specs is trying to overcome the basic
fact that there is no reasonable, SINGLE choice. Rather than pretend
that a 'framework' for a global solution can be found, let me very, very
strongly caution people to step back and think very hard about the
impact of the current approaches. I content that they will tend to
increase the already-rampant entropy on the EMail Internet and make it
substantially less usefull.
Dave