Re: Negotiated noncompliance
Eliot Lear <lear@cisco.com> Thu, 17 August 2000 08:35 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 EAA22389 for <drums-archive@odin.ietf.org>; Thu, 17 Aug 2000 04:35:35 -0400 (EDT)
Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id EAA03633; Thu, 17 Aug 2000 04:35:16 -0400 (EDT)
Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 17 Aug 2000 04:35:14 -0400
Received: by cs.utk.edu (cf v2.9s-UTK) id EAA03613; Thu, 17 Aug 2000 04:35:13 -0400 (EDT)
Received: from lint.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id EAA03600; Thu, 17 Aug 2000 04:35:12 -0400 (EDT)
Received: from lint.cisco.com (171.68.224.209 -> lint.cisco.com) by cs.utk.edu (smtpshim v1.0); Thu, 17 Aug 2000 04:35:12 -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id BAA08687; Thu, 17 Aug 2000 01:35:07 -0700 (PDT)
Message-ID: <399BA325.55A39FA3@cisco.com>
Date: Thu, 17 Aug 2000 01:32:37 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: John Gardiner Myers <jgmyers@netscape.com>
CC: drums@cs.utk.edu
Subject: Re: Negotiated noncompliance
References: <399B23B3.A53EC392@netscape.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:drums-request@cs.utk.edu?Subject=unsubscribe>
Content-Transfer-Encoding: 7bit
I would like to see discussion open as well. And since I'm number 4 on the list as far as I can tell (John, Keith, Paul, me), I'm gonna open it right here. I agree with the sentiment behind the wording. May I propose an alternative, to be inserted in or around section 6.3, as the editor sees fit? -- This standard takes a stricter tone than its predecessor. It does so with the experience of nearly twenty years of odd interoperability failures, and with the realization that where-as thousands of people used SMTP at the time of RFC 821, now millions of people rely on the standard. Non-conformance, therefore, can be far more costly. 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. However, it does risk misinterpreting the intent of the other implementation, which may lead to altered or lost messages, protocol deadlocks, or other failures. Thus great care must be taken in such circumstances. -- This is not a matter of "negotiated noncompliance" but more a matter of dealing with an implementation's failure to comply with the words in the document. John Gardiner Myers wrote: > > I propose the following additional wording for resolving the "naked LF" > issue: > > Section 2.3.7, in "Conforming implementations MUST NOT recognize or > generate any other..." remove "recognize or". > > Add: > > 6.4 Negotiated Noncompliance > > A general protocol implementation principle may be useful to > implementations which wish to interoperate with particular types of > noncompliant peers: If an implementation receives protocol which is not > permitted by the specification and the specification does not mandate > the response to such illegal protocol, the implementation MAY consider > the peer to have negotiated a nonstandard protocol. At that point, the > implementation is not constrained by the protocol specification in its > handling of that particular connection. > > For example, if an SMTP server receives commands terminated by the ASCII > character "LF" but not containing the ASCII character "CR", it MAY > consider the SMTP client as having negotiated a nonstandard variant of > the SMTP protocol wherein the <CRLF> sequence is encoded as a single > "LF" character. The prohibition against recognizing the sequence > "<LF>.<LF>" as the end of mail data indication would then not apply to > that particular connection. > > Note that this negotiation does not release the implementation from the > conformance requirements in any other protocol session, including any > session that relays mail received from a negotiated nonstandard protocol > variant. -- Eliot Lear lear@cisco.com
- Negotiated noncompliance John Gardiner Myers
- Re: Negotiated noncompliance Dave Crocker
- Re: Negotiated noncompliance Keith Moore
- Re: Negotiated noncompliance Paul Hoffman / IMC
- Re: Negotiated noncompliance Keith Moore
- Re: Negotiated noncompliance Eliot Lear
- Re: Negotiated noncompliance Dave Crocker
- Re: Negotiated noncompliance Eliot Lear
- Re: Negotiated noncompliance Charles Lindsey
- Re: Negotiated noncompliance Keith Moore
- Re: Negotiated noncompliance Barry Leiba
- Re: Negotiated noncompliance Chris Newman
- Re: Negotiated noncompliance John Gardiner Myers
- Re: Negotiated noncompliance John Gardiner Myers
- Re: Negotiated noncompliance Charles Lindsey
- Re: Negotiated noncompliance Philip Hazel
- Re: Negotiated noncompliance DRUMS WG Chair
- Re: Negotiated noncompliance Eliot Lear
- Re: Negotiated noncompliance Keith Moore
- Re: Negotiated noncompliance Robert Elz
- Re: Negotiated noncompliance Philip Hazel
- Re: Negotiated noncompliance Robert Elz
- Re: Negotiated noncompliance Charles Lindsey
- Re: Negotiated noncompliance D. J. Bernstein
- Re: Negotiated noncompliance Russ Allbery
- Re: Negotiated noncompliance Claus Färber
- Re: Negotiated noncompliance Harald Alvestrand
- Re: Negotiated noncompliance Graham Klyne
- Re: Negotiated noncompliance Barry Finkel