Re: 2nd suggested revision for MUST/SHOULD

Charles Lindsey <chl@clw.cs.man.ac.uk> Fri, 28 July 2000 11:14 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 HAA17669 for <drums-archive@odin.ietf.org>; Fri, 28 Jul 2000 07:14:12 -0400 (EDT)
Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA29444; Fri, 28 Jul 2000 07:13:45 -0400 (EDT)
Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 07:13:43 -0400
Received: by cs.utk.edu (cf v2.9s-UTK) id HAA29427; Fri, 28 Jul 2000 07:13:43 -0400 (EDT)
Received: from probity.mcc.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id HAA29414; Fri, 28 Jul 2000 07:13:39 -0400 (EDT)
Received: from probity.mcc.ac.uk (130.88.200.94 -> probity.mcc.ac.uk) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 07:13:40 -0400
Received: from nessie.mcc.ac.uk ([130.88.200.20] ident=root) by probity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 13I85C-0009Vs-00 for drums@cs.utk.edu; Fri, 28 Jul 2000 12:13:38 +0100
Received: from clw.cs.man.ac.uk (clerew.man.ac.uk [194.66.22.208]) by nessie.mcc.ac.uk (8.9.3/8.8.8) with ESMTP id MAA50859 for <drums@cs.utk.edu>; Fri, 28 Jul 2000 12:13:35 +0100 (BST) (envelope-from root@clw.cs.man.ac.uk)
Received: (from root@localhost) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) id JAA07095 for drums@cs.utk.edu; Fri, 28 Jul 2000 09:39:23 +0100 (BST)
Received: from localhost (localhost [127.0.0.1]) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) with SMTP id JAA07092 for <drums@cs.utk.edu>; Fri, 28 Jul 2000 09:39:22 +0100 (BST)
Message-Id: <200007280839.JAA07092@clw.cs.man.ac.uk>
Date: Fri, 28 Jul 2000 09:39:22 +0100 (BST)
From: Charles Lindsey <chl@clw.cs.man.ac.uk>
Reply-To: Charles Lindsey <chl@clw.cs.man.ac.uk>
Subject: Re: 2nd suggested revision for MUST/SHOULD
To: drums@cs.utk.edu
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: <mailto:drums-request@cs.utk.edu?Subject=unsubscribe>

	On Thu, 27 Jul 2000 23:30:45 -0400
	Keith Moore <moore@cs.utk.edu> 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)
                                                                ^
                                                                conforming
> 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
                                                      ^
                                                      Some
> 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:     chl@clw.cs.man.ac.uk  Web:   http://www.cs.man.ac.uk/~chl
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