From: Robert Elz <kre@munnari.OZ.AU>
To: drums@cs.utk.edu
Subject: Re: Syntax extensions in RFC 821 
In-Reply-To: Your message of "08 Feb 1999 06:50:16 -0000."
             <19990208065016.27022.qmail@cr.yp.to> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 08 Feb 1999 18:19:09 +1100
Message-Id: <18117.918458349@munnari.OZ.AU>
Sender: kre@munnari.OZ.AU

    Date:        8 Feb 1999 06:50:16 -0000
    From:        "D. J. Bernstein" <djb@cr.yp.to>
    Message-ID:  <19990208065016.27022.qmail@cr.yp.to>

  | Katie Hafner and Matthew Lyon quote Jon Postel as writing

And that I fully believe.   That would have related to the mail content
itself though, not to the smtp transaction, where there is very little
room for variation.

  | As I said before, he understood the difference between
  |    * _accepting_ syntax extensions---``nice''---and
  |    * _sending_ syntax extensions---``violation of the standard.''

Yes.   And no, I am not confusing those.   You are if you believe that
taking notice of a 200 reply is "accepting a syntax extension".   A 200
reply to a DATA command (meaning "send me the data") could never be a
syntax extension, it would be a total redefinition of 821 reply codes.

One could imagine a syntax extension where 200 to a DATA command might
mean that the data had already been accepted, or wasn't needed, or similar.
In that case, sending the data would be fundamentally wrong.

Next, (to avoid sending unnecessary messages), in reply to Elliot Lear
you claimed that someone is wanting to punish some users or other.

Nonsense.    User's clients/servers will continue to work after 821bis
appears just as well (or not) as they do now.   No users will suffer.
Some implementors may not be able to simply claim (without doing any work)
"my server is 821bis conformant", but that is the only effect.   There is
no-one about to go racing about attempting to test anyone's servers for
821bis conformance and banish those which do not conform (any more than
there has for 821 conformance).

Lastly, no-one I know of admits that buggy servers MUST NOT be deployed on
the internet - if that were a requirement we would have had almost no
servers on the internet, and most likely still would have none.   There will
always be servers with all kinds of bugs.   As much as is reasonably possible,
clients must be perpared to deal with those bugs (just as servers ought to
deal with bugs in clients).   "Deal with" here means to operate in some
reasonable and defined way, with the primary aim of not losing mail.
Validating that the server is generating some reasonable reply code, and
treating it as either broken, or at least temporarily confused, is one obvious
way of achieving that.

In any case, it appears that there is no-one else here who has any sympathy at
all with your view - and it doesn't appear that you're changing anyone's
mind.   Give up.

kre