Re: Responsive vendors and their implications (was de-facto 8 bit smtp)

[Nathaniel Borenstein <nsb@xxxxxxxxxxxxxxxxxxxx>]

Excerpts from internet.ietf-smtp: 22-Feb-91 Responsive vendors and
thei.. John C Klensin@infoods.m (3648)

> There is another point here, which has been said in other contexts, and 
> I think bears repeating.  There are a lot fewer SMTP MTAs out there than
>  there are UAs that handle RFC822.  The MTAs tend to be part of TCP/IP 
> packages, supported by a relatively small number of vendors, and, at 
> maximum, there will be one running per host.  The UAs, by contrast, tend
>  to be more subject to user whim: it is not unusual to have more than
> one  MUA on a given host, providing different interfaces or whatever and
> I  suspect there are more homegrown ones.  So, from a speed of
> deployment  standpoint, almost anything that is changed in the SMTP/MTA 
> specification is going to be out there as rapidly or more rapidly than 
things that require that most of the UAs in the world be changed.

This argument would make sense if there were any reason for the UA's to
change, period.  The point is, however, that if you change SMTP, all
MTA's MUST change.  If you change RFC 822, UA's don't need to change
unless their users are actually going to be exchanging multimedia mail. 
In other words, you don't have to change the whole world to make it
start working properly for the people who are playing the new game.

If changing every UA were necessary for the only-change-822 scheme, then
changing 821 would indeed be the better option.  But that's not really
the right alternative.  If we change 822, the UA's can change gradually
or never, depending on the needs of their user communities.