Re: Negotiated noncompliance

John Gardiner Myers <jgmyers@netscape.com> Thu, 17 August 2000 20:17 UTC

Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03962 for <drums-archive@odin.ietf.org>; Thu, 17 Aug 2000 16:17:18 -0400 (EDT)
Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA07178; Thu, 17 Aug 2000 16:16:51 -0400 (EDT)
Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 17 Aug 2000 16:16:50 -0400
Received: by cs.utk.edu (cf v2.9s-UTK) id QAA07161; Thu, 17 Aug 2000 16:16:50 -0400 (EDT)
Received: from netscape.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA07139; Thu, 17 Aug 2000 16:16:48 -0400 (EDT)
Received: from netscape.com (205.217.237.46 -> h-205-217-237-46.netscape.com) by cs.utk.edu (smtpshim v1.0); Thu, 17 Aug 2000 16:16:48 -0400
Received: from u-gotmail.red.iplanet.com (u-gotmail.red.iplanet.com [192.18.73.45]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7HK5Ee08261 for <drums@cs.utk.edu>; Thu, 17 Aug 2000 13:05:19 -0700 (PDT)
Received: from netscape.com (jgmyers-nt.red.iplanet.com [192.18.126.70]) by we-gotmail.red.iplanet.com (iPlanet Internet Mail Server 5.0 (built Jul 22 2000)) with ESMTPS id <0FZG008OGDPEK6@we-gotmail.red.iplanet.com> for drums@cs.utk.edu; Thu, 17 Aug 2000 13:17:41 -0700 (PDT)
Date: Thu, 17 Aug 2000 13:14:41 -0700
From: John Gardiner Myers <jgmyers@netscape.com>
Subject: Re: Negotiated noncompliance
To: drums@cs.utk.edu
Message-id: <399C47B1.1876CA7E@netscape.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.74 [en] (WinNT; U)
Content-type: multipart/signed; boundary="------------ms00267482E4EF8164B375B203"; micalg="sha1"; protocol="application/x-pkcs7-signature"
X-Accept-Language: en
References: <399B23B3.A53EC392@netscape.com> <4.3.2.20000816163616.00cb2c70@mail.bayarea.net>
List-Unsubscribe: <mailto:drums-request@cs.utk.edu?Subject=unsubscribe>


Dave Crocker wrote:
> Besides being on the wrong side of a slippery slope, this sort of language
> will only serve to make the distinction between "in spec" and "out of spec"
> more confused than it already is.

How does this make the distinction more confused?  The wording lists a
specific set of preconditions which must be satisfied in order for an
implementation to legitimately claim the specification does not apply.
 
> Any two consenting protocol engines may do anything they wish, in the
> privacy of their own interactions.

This is absolutely incorrect.  It is this kind of wording, berefit of
necessary preconditions, that adds the kind of confusion complained
about.  A protocol engine must have reasonable proof that it is talking
to a peer that does not expect conformance before varying from the
specification.  Otherwise, it might "do anything they wish" with a peer
which is expecting conformance.

Eliot Lear's proposed wording:

> If one implementation in an SMTP conversation demonstrates its failure
> to comply with this standard, the other implementation MAY vary from
> this standard if its developer believes it has sufficient knowledge as
> to the intent of the other side.

is similarly too lax.  It is not sufficient that the peer demonstrate
failure to comply with the standard, it is also necessary that the
standard not require the implementation to react to that demonstration
in a particular way.

Part of the issue is that section 2.3.7 currently prohibits
implementations from recognizing a naked LF as a command line
terminator.  Unless the two words "recognize or" are removed, conforming
implementations have no freedom to handle this particular type of error.