...Maybe it is hopeless. If it is, MTA designers should start making
plans about what they are going to do when they see 8bit characters
flying through (or at) SMTP servers without the protections of either
negotiated options or the structures and identifying information of
RFC-XXXX....
Maybe my experiences are abnormal, but this seems to be a statement from
1988. Even if we succeed in persuading some 8-bit users that this new mail
software which allows for enhanced features is worth buying and/or installing
(and I, like Mark, and John, dearly do hope we in pursuading people to
transition away from their existing 8-bit software), unnegotiated 8bit SMTP
traffic will be flying about for some time.
In this context, I oppose binary transport for all the reasons Mark
and I have raised and one more: if it gets bound to 8bit character
transport extensions to SMTP, I think they will go down in flames
together...
As long as we're all making 'for the record comments', as one of the binary
transport proponents I hereby state that if binary and negotiated 8-bit
transport are bound together we've done binary wrong.
I think this is an area where Greg seriously disagrees with me (just to
identify another possible position) and that may be why some of these
issues keep coming up.
If Atlanta was any indication, by a rather overwhelming majority the IETF
is in favor of extending SMTP to include binary transport. It is indeed
confusing why these issues keep coming up (:-)).
More seriously, your concern that negotiated 8-bit transport not 'go down
in flames' is valid. However, it is clear that both the IETF and the vendor
community are committed to making both negotiated 8-bit and binary capable
SMTP implementations available to the world's user community.
enjoy,
leo j mclaughlin iii
ljm(_at_)ftp(_dot_)com