Re: 2nd suggested revision for MUST/SHOULD

Charles Lindsey <> Fri, 28 July 2000 11:14 UTC

Received: from (CS.UTK.EDU []) by (8.9.1a/8.9.1a) with ESMTP id HAA17669 for <>; Fri, 28 Jul 2000 07:14:12 -0400 (EDT)
Received: from localhost (daemon@localhost) by with SMTP (cf v2.9s-UTK) id HAA29444; Fri, 28 Jul 2000 07:13:45 -0400 (EDT)
Received: by (bulk_mailer v1.13); Fri, 28 Jul 2000 07:13:43 -0400
Received: by (cf v2.9s-UTK) id HAA29427; Fri, 28 Jul 2000 07:13:43 -0400 (EDT)
Received: from (marvin@localhost) by with ESMTP (cf v2.9s-UTK) id HAA29414; Fri, 28 Jul 2000 07:13:39 -0400 (EDT)
Received: from ( -> by (smtpshim v1.0); Fri, 28 Jul 2000 07:13:40 -0400
Received: from ([] ident=root) by with esmtp (Exim 2.05 #4) id 13I85C-0009Vs-00 for; Fri, 28 Jul 2000 12:13:38 +0100
Received: from ( []) by (8.9.3/8.8.8) with ESMTP id MAA50859 for <>; Fri, 28 Jul 2000 12:13:35 +0100 (BST) (envelope-from
Received: (from root@localhost) by (8.9.1b+Sun/8.9.1) id JAA07095 for; Fri, 28 Jul 2000 09:39:23 +0100 (BST)
Received: from localhost (localhost []) by (8.9.1b+Sun/8.9.1) with SMTP id JAA07092 for <>; Fri, 28 Jul 2000 09:39:22 +0100 (BST)
Message-Id: <>
Date: Fri, 28 Jul 2000 09:39:22 +0100 (BST)
From: Charles Lindsey <>
Reply-To: Charles Lindsey <>
Subject: Re: 2nd suggested revision for MUST/SHOULD
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: eSTzKGCN269Jnq3DbvLgnQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc
List-Unsubscribe: <>

	On Thu, 27 Jul 2000 23:30:45 -0400
	Keith Moore <> said...

> several points:
> I see no inherent problem with copying the 2119 definitions for 
> MUST/SHOULD.  However I assume that much of the existing text is 
> based on the 1123 definitions of these terms, so changing might
> require examining every occurance of these terms.  Fortunately,
> the 1123, 2119, and proposed definitions of these terms are quite
> similar.  And I do see value in consistency with 2119, though
> RFCs which deviate from the 2119 definitions are not uncommon.
> However I wonder if the definitions of "fully conforming" 
> vs. "partially conforming" may still be useful, regardless of which
> definitions of MUST/SHOULD are used.  OTOH, I do have some 
> reservations about defining "fully/partially conforming" in this way 
> because (if memory serves) SHOULD [NOT] are sometimes used to avoid 
> having to specify the behavior of each particular kind of MTA 
> configuration.  An SMTP implementation that, for whatever valid 
> reason, doesn't perform every single one of the functions of an MTA 
> (submission, delivery, relaying, aliasing, list expansion, etc) 
> should perhaps be "fully conforming" as long as it meets the 
> SHOULD [NOT] requirements for the functions that it does perform.
> I also think that it's worthwhile to explain 
> - why SHOULD or even MUST might specify something that degrades
> interoperability with noncomforming implementations of this or
> a previous specification.  (interoperability with conforming
> implementations is paramount)
> - that the spec is deliberately tightened as compared to previous
> versions; pre-existing implementations are expected to require
> some changes
> no matter which definitions of MUST/SHOULD/MAY are used.
> personally, I don't think that consistency with 2119 is so important 
> that it necessiates changing the document at this late date.
> but if it helps us get consensus on the document, it might be worth it.
> so at the risk of bogging things down more, here is a 2nd concrete 
> proposal.  the paragraphs not in 2119 are labelled [A], [B], and [C]
> for easy reference in DRUMS discussion, not for inclusion in the
> RFC.

Yes, I think that is better, because the relationship to 2119 is now clear.

But I see little point in repeating the 2119 text in full. Other standards just 
refer to it.

A couple of nit picks:

> [B] ...
> type of implementation) to not follow the requirement.
                          not to follow
                       (split infinitive :-( )
> [C] In some cases this document imposes "MUST" and/or "SHOULD"
> requirements which deviate from a significant body of current practice
> at the time of this writing.  In such cases these requirements are
> imposed when experience indicates that following such requirements
> is likely to lead, in practice, to better interoperation, or
> smoother operation of the Internet email infrastructure.   Though
> this document does attempt to ensure that (fully or partially)
> implementations of this specification will interoperate with
> (fully or partially) conforming implementations of its predecessors,
> it does not attempt to legitimize common deviations from those
> specifications, and it does impose new requirements.  Existing
> implementations of SMTP will need some changes if they are to
> conform to this new specification.

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:  Web:
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5