It is a rare day when I say what I am about to say:
Bravo, Mark. Good argument, succinctly expressed.
So, can we dispense with the 8 bit and binary transport nonsense, and
simply encode everything now, like we should have in the first place?
Parochial as some may say this view is, I think it is important to
affirm the 7bit-ness and ASCII-ness of SMTP, and leave it be. If you
want to move arbitrary bundles of bits through SMTP, encode. Don't mess
around with a well understood, working mail transport protocol & system.
If the extra bit in the octets is *that* important to you, then we need
to talk about a new protocol, on a new TCP port, especially optimized
to move lots of data very fast with as few end-to-end turn-arounds as
possible (since it seems to be the argument that the efficiency gained
by binary transport will become worth it when the messages get "large"
for some value of large - why slow it down with per-user address
validation?). If it is important for everyone to speak this new
transport, then we have to talk about a transition schedule and a
designated gateway or two (udel-relay, anyone?), as was mentioned on
this list (or its evil twin ietf-smtp) some months ago.
In my capacity as Postmaster for Apple Computer, Inc., I will shortly
be issuing a TechNote to our developers (in house and third party)
which describes a standard for encapsulating an arbitrary Macintosh
file in Internet mail (with the caveat that the IETF may eventually
provide something more functional, and implementors should implement
that when it comes along), because I can't wait for this group to
complete its deliberations. My users are demanding this capability now
(indeed, they have been waiting for me to implement it for over a
year), and I can't stall 'em any longer.
Erik E. Fair apple!fair fair(_at_)apple(_dot_)com