I have received a number of public and private comments on my original
SMTP/8 and 822/8 posting. Let me attempt to answer the major comment:
* These ideas have been discussed on these lists before. Why are you
* bringing them up again?
Engineering solutions are not matters of absolutes but of cost-benefit
tradeoff. The other solutions being proposed on this list are just too
complex (and seem to get more complex with each passing month). I
believe that it is proper to reevaluate the assumptions that have lead
to this complexity.
Much of the complexity results from an earlier "decision" that:
*ALL* *NEW* functionality *MUST* fit through SMTP/7 and 822/7.
I believe this decision is the source of much grief and must be
reexamined. I wholeheartedly agree that:
*ALL* *OLD* functionality must continue to interoperate with
SMTP/7 and 822/7.
For this reason, we are ammending the "defacto" RFC to *REQUIRE* some
features that protect 7-bit mailers and mail-readers from the effects
of octets (like registered trademark) which, when bit-stripped, may
confuse SMTP DATA exchange or mail-reader parsing of "structured"
header fields.
I also believe that:
It is *HIGHLY DESIRABLE* that *NEW* functionality fit through
SMTP/7 and 822/7.
For this reason, I support the position that "binary" encodings should
result in lines of printable ASCII-7 not to exceed 78 characters in
length.
HOWEVER, all of the work to force non-ASCII-7 characters into 7-bits is
leading to more cost than it is worth.
I believe: We don't need all the extra header fields and questionably
parsable multi-part techniques. AUC/10646 and extensions to 1154 will
handle all of this in a simple, consistent fashion.
You don't have to agree, but as engineers you need to evaluate the
cost-benefits of what we propose compared to the alternative currently
under discussion.
Flame-broiled on both sides,
David