Date: Tue, 31 Dec 1996 13:04:19 -0500 (EST)
From: John C Klensin <klensin@mail1.reston.mci.net>
Subject: Re: blank line as head/body separator (actually: case sensitivity)
In-reply-to: <961231114737.ZM25536@chrome.office.aol.com>
Sender: klensin@mail1.reston.mci.net
To: KnowlesB@aol.net
Cc: drums@cs.utk.edu
Message-id: <SIMEON.9612311319.W@white-box.mail1.reston.mci.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL


On Tue, 31 Dec 1996 11:47:36 -0500 Brad Knowles 
<BKnowles@aol.net> wrote:
>...
>     Therefore, the MS-Mail SMTP Gateway that requires the use of
> uppercase is broken as a server, and must be fixed (no ifs, ands
> or buts).  Meanwhile, to deal with the legacy issue, we make the
> further requirement that all clients must be written such that 
>...
>     Some currently conforming clients may become non-conformant,
> but there is time to get them fixed.  Clients that are 
> orphaned (no further work is being done on them) or on which the 
> authors refuse to conform to the new standard, would at some 
>...

Brad,

I want to make sure I understand this argument before I tell 
you what I think of it:

 (i) We have seen a few non-conforming SMTP receivers out 
there. Our best example of such a receiver is a product (the 
MS-Mail SMTP gateway) whose vendor thinks it is obsolete and 
should be replaced by a newer/upgraded product (which, 
incidentally, is case-insensitive).  To put that differently, 
whatever the problems with the MS-Mail SMTP gateway were, 
Microsoft believes they have been fixed: some of the most 
obnoxious problems in early versions were fixed in later 
versions (but some sites haven't upgraded), and many of the 
problems in the last version have been repaired in Exchange 
Server and its "Internet Mail Connector" (which I believe is 
considered to be the replacement product) or one of their other 
product offerings.

 (ii) We have a selection of SMTP-senders out there that work 
well, and have worked well for years, with almost all of the 
SMTP-receivers deployed on the Internet.  Those senders 
include, as Kai points out, some lower-case-sending people as 
well as some lower-case-sending software products.  Because of 
this small number of SMTP receivers that contain this 
particular non-conforming property, we are going to risk 
breaking those existing conforming implementations by imposing 
rules and deadlines to which they may or may not be able to 
conform.

In addition...

 (iii) We have a long history of implementers who get a little 
sloppy in reading specs and who interpret a migration path as 
license to do something Right Now.  If we change the rules to 
state that receivers may eventually reject non-upper-case 
verbs, we will certainly see more, not fewer, implementations 
that behave the way the MS-Mail SMTP gateway (and its admirers) 
does.  Those implementation are broken, of course, but now we 
have indirectly encouraged more broken implementations as well 
as declaring some things that have been conforming for the last 
nearly-20 years to be broken.  That doesn't feel to me like a 
net gain.

  (iv) Since you picked out the MS-Mail SMTP Gateway product 
as an example, let's see where that argument leads.  It turns 
out, as I hope you know (I'm certain many readers of this list 
do) that the implementation and conformance quality of that 
product are, shall we say, legendary.  Now, as a quality of 
implementation issue, several producers/vendors of SMTP server 
products have essentially created combinations of features and 
options that amount to an "MS Mail SMTP Gateway" mode -- 
features that might include not only avoiding lower-case verbs 
but also, for example, mechanisms for coping with the 'one 
connection at a time', 'if I don't like what you sent, I'll 
just close the connection', and rather creative reply code set 
that appeared with different versions of that product.   But 
I'm interested in whether, by extension of the case sensitivity 
argument you are making, you would advocate additional changes 
to the protocols to avoid problems with things that behave the 
way the MS-Mail SMTP Gateway behaves.  And if not, why not?

 (v) If we are going to do that job for the MS-Mail SMTP 
Gateway, would similar principles apply to contemporary (rather 
than obsolete) products?  There are, for example, all sorts of 
interesting changes we could make to MIME, to say nothing of 
the SMTP extension mechanism, that would make interworking with 
the weak gateways associated with various LAN-based mail 
systems easier.  And, of course, things would work ever so much 
better if we dropped all of this "multimedia" and "multiple 
character set" stuff and just confined ourselves to short text 
messages in ASCII.

I guess I just don't follow the logic.  Either that or we 
disagree about the principle that we make incompatible 
(or incompatibility-producing) changes to mature protocols when 
we see interoperability problems among _conforming_ 
implementations, and perhaps when we see overwhelming 
efficiency or economic gains, but we otherwise don't mess with 
the infrastructure.    And, if we drop that principle, I'd bet 
we could find ever so many more interesting and effective 
changes to make to SMTP than messing around with case 
comparisons.

 happy new year
    john