Re: Negotiated noncompliance
Eliot Lear <lear@cisco.com> Wed, 23 August 2000 11:51 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 HAA09197 for <drums-archive@odin.ietf.org>; Wed, 23 Aug 2000 07:51:12 -0400 (EDT)
Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA13673; Wed, 23 Aug 2000 07:50:23 -0400 (EDT)
Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 23 Aug 2000 07:50:16 -0400
Received: by cs.utk.edu (cf v2.9s-UTK) id HAA13655; Wed, 23 Aug 2000 07:50:15 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id HAA13640; Wed, 23 Aug 2000 07:50:13 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (171.71.163.11 -> sj-msg-core-1.cisco.com) by cs.utk.edu (smtpshim v1.0); Wed, 23 Aug 2000 07:50:14 -0400
Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id EAA05330; Wed, 23 Aug 2000 04:50:10 -0700 (PDT)
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id GAA00733; Wed, 23 Aug 2000 06:49:47 -0500 (CDT)
Message-ID: <39A3B55A.C59344D2@cisco.com>
Date: Wed, 23 Aug 2000 04:28:26 -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: drums@cs.utk.edu
CC: John Gardiner Myers <jgmyers@netscape.com>
Subject: Re: Negotiated noncompliance
References: <399BA325.55A39FA3@cisco.com> <63058.3175504784@nifty-jr.west.sun.com> <399C525D.4994182B@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 separate two issues: wording of section 6.4 and whether we strike "recognize" in section 2.3.7. In reverse order, I believe we are at or near consensus on Chris' wording, taking into account John's and Philip's changes. Do others disagree? 6.4 Interoperability with Noncompliant Implementations This standard takes a stricter tone than its predecessor in order to discourage deployment of non-complaint software and to prevent harm caused by poorly designed attempts to interoperate with deployed non-compliant software. It does so with the experience of nearly twenty years of odd interoperability failures, and with the realization that whereas 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 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 can treat this as a negotiated a non-standard protocol. At that point, the implementation is not constrained by the protocol specification in its handling of that particular connection. Implementations which choose to do this SHOULD narrowly tailor the accepted non-compliant protocol to that strictly necessary to interoperate with known deployed non-compliant software. For example, if an SMTP server receives commands terminated by the ASCII character "LF" but not containing the ASCII character "CR", it can decide the SMTP client has 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. ------- We are NOT in complete agreement on what to do about section 2.3.7, but I believe we are arguing between a MUST/SHOULD and striking the word "recognize". As I wrote earlier, I could survive with SHOULD, but would still prefer MUST, and I would not wish to hold up the draft in any event. My argument is that 6.4 should be taken into consideration wrt 2.3.7 as it would be with other parts of the document. The document doesn't mandate a RESPONSE to naked LFs. It merely states they should not be "recognized" as <CRLF>s. Comments? -- 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