Subject: suggested revision for MUST/SHOULD

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jul 2000 11:15:02 -0400

this is a very slight rewording; were it not for the controversy
surrounding the subject I would have submitted it to the author
as an editorial change.  however I do think a slight bit of 
tweaking is worthwhile here.

> The terms "MUST" and "SHOULD" (and "MUST NOT" and "SHOULD NOT") are
> used in the same general sense here as in the Host Requirements
> Standards [RFC-1123].  Specifically, "MUST" or "MUST NOT" identify
> absolute requirements for conformance to this specification.
> Implementations that do not conform to them lie outside the scope of
> this specification.  Implementations that are fully conforming also 
> adhere to all "SHOULD" and "SHOULD NOT" requirements.  Implementations 
> that adhere to all "MUST" ("MUST NOT") but not to all of these are 
> considered to be partially conforming.  

( separate the definitions of "fully" and "partially" conforming
from the text that explains when MUST/SHOULD/etc are used, so that
the latter is clearly distinguished. )

> "MUST" and "MUST NOT" are generally used when the requirement is 
> necessary to ensure robust interoperation between conforming
> implementations.  "SHOULD" and "SHOULD NOT" are also used to
> describe cases where the requirement is necessary for robust
> interoperation between (fully or partially) conforming 
> implementations, but when it is recognized that there may be 
> valid reasons for a particular implementation (or a particular
> type of implementation) to not follow the requirement.
> An implementation should violate "SHOULD" or "SHOULD NOT"
> requirements only under exceptional circumstances, and when great
> care has been taken to understand the implications of that choice.

1. suggested text is even more careful to say 'conforming' implementations.
nowhere does it say anything about interoperation between noncomforing
implementations, or between a conforming implementation and a noncomforming
one.  so for instance "MUST reject bare LF" does not interfere with
interoperability between conforming implementations.

2. says that MUST/SHOULD are "generally" used when needed for
interoperation...to allow room for other good reasons to use them.

3. slight rewording of when to violate SHOULD 

> 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. 

separate paragraph to explain use of MUST/SHOULD which deviates 
from current practice (since this seems to be a common source of
confusion).  the stuff about "not legitimizing common deviations"
and "we didn't try to write the spec so that existing implementations 
would automatically be conforming" might be a bit over the top, or 
it might be better placed elsewhere, but again, it does seem to be 
a common source of confusion.

> Statements using "MAY" describe features or styles of doing things that 
> may be followed, or not, at the discretion of the implementation, 
> normally without causing significant interoperability problems.

Keith

---

From: DRUMS WG Chair <[email-masked]>
Date: Thu, 27 Jul 2000 13:38:03 -0700

If you support Keith's proposed wording change, please speak up now.

If three people (in addition to Keith) express support, the issue will be 
open for objections and debate.  Otherwise we will keep the current wording 
in draft 12.

		- DRUMS WG Chair

--On Thursday, July 27, 2000 11:15 -0400 Keith Moore <[email-masked]> 
wrote:
> 1. suggested text is even more careful to say 'conforming'
> implementations. nowhere does it say anything about interoperation
> between noncomforing implementations, or between a conforming
> implementation and a noncomforming one.  so for instance "MUST reject
> bare LF" does not interfere with interoperability between conforming
> implementations.
>

---

From: "Bart Schaefer" <[email-masked]>
Date: Thu, 27 Jul 2000 14:05:46 -0700

On Jul 27,  1:38pm, DRUMS WG Chair wrote:
> Subject: Re: suggested revision for MUST/SHOULD

I support this change.

---

From: Michael Scharff <[email-masked]>
Date: Thu, 27 Jul 2000 14:19:34 +0100

I too will support this change.

---

From: DRUMS WG Chair <[email-masked]>
Date: Thu, 27 Jul 2000 15:21:00 -0700

The proposed replacement text on this topic has sufficient support to be 
considered.  If you object to the proposed replacement text to the extent 
that you want to prolong this working group, please reply to this thread 
with the following information:

(1) A description of the technical basis for your objection.

(2) State whether or not you prefer the proposed replacement text to the 
text in draft 12.

(3) Include alternative replacement text if you find both options 
unacceptable to the extent that you wish to prolong the working group.

Debate about the technical basis for any proposed replacement text is also 
appropriate at this time, but please be concise.

If there are no objections to the proposed replacement text, I will direct 
the document editor to include it in draft 13.

		- DRUMS WG Chair

---

From: "D. J. Bernstein" <[email-masked]>
Date: 27 Jul 2000 22:53:47 -0000

I agree that this needs discussion.

However, I have a different suggestion: the definitions of ``SHOULD'' et
al. should simply be copied from RFC 2119, with no extra text.

(I say ``copied'' rather than ``incorporated by reference'' to avoid the
issue of whether smtpupd is obliged to follow RFC 2119, section 6.)

Most readers will be expecting the RFC 2119 definitions. Many readers
will misinterpret the document if it uses anything else---they'll never
realize that there are new definitions.

I've checked a bunch of ``SHOULD''s in the document, and they all seem
to predate the new definitions, which appeared in smtpupd-09. Presumably
they were written with the RFC 2119 (or almost identical RFC 1123)
definitions in mind. The new definitions seem to have screwed up the
meaning of these ``SHOULD''s.

---Dan

---

From: "Eric S. Raymond" <[email-masked]>
Date: Thu, 27 Jul 2000 19:29:54 -0400

> meaning of these ``SHOULD''s.

I think this is a good suggestion.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

No matter how one approaches the figures, one is forced to the rather
startling conclusion that the use of firearms in crime was very much
less when there were no controls of any sort and when anyone,
convicted criminal or lunatic, could buy any type of firearm without
restriction.  Half a century of strict controls on pistols has ended,
perversely, with a far greater use of this weapon in crime than ever
before.
        -- Colin Greenwood, in the study "Firearms Control", 1972

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 27 Jul 2000 18:21:06 -0700

>I think this is a good suggestion.

I agree with Dan and Eric. A typical implemetor will assume that MUST 
and SHOULD are used as they are in every other mail standard, namely 
as they are stated in 2119.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jul 2000 23:30:45 -0400

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.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
"OPTIONAL" in this document are to be interpreted as follows:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

[A] An implementation that does not adhere to each of the "MUST" and "MUST 
NOT" requirements is not considered to be conforming to this specification.
An implementation that adheres to each of the "MUST" and "MUST NOT"
requirements, but does not adhere to each of the "SHOULD" and "SHOULD NOT"
requirements, is considered to be partially conforming to this 
specification.  An implementation that adheres to all requirements is 
considered to be fully conforming.  There is no intention or expectation 
that partially or fully conforming implementations of this specification 
will interoperate with nonconforming implementations of either this 
specification or its predecessors.

[B] "MUST" and "MUST NOT" are generally used when the requirement is

[C] In some cases this document imposes "MUST" and/or "SHOULD"

---

From: DRUMS WG Chair <[email-masked]>
Date: Fri, 28 Jul 2000 16:35:33 -0700

> realize that there are new definitions.

The document editor has privately told me he is agreeable to the proposal 
to copy the definitions from RFC 2119 under the condition that there is a 
review of all MUST/SHOULD usage in the draft relative to the changed 
meanings.  Paul Hoffman has volunteered to perform that review.  If no one 
objects, I will ask Paul to perform that review and post proposed text 
changes (if any are needed) to the list for consideration.

		- DRUMS WG Chair

---

From: Russ Allbery <[email-masked]>
Date: 28 Jul 2000 17:14:59 -0700

DRUMS WG Chair <[email-masked]> writes:

> The document editor has privately told me he is agreeable to the
> proposal to copy the definitions from RFC 2119 under the condition that
> there is a review of all MUST/SHOULD usage in the draft relative to the
> changed meanings.  Paul Hoffman has volunteered to perform that review.
> If no one objects, I will ask Paul to perform that review and post
> proposed text changes (if any are needed) to the list for consideration.

I was hesitating on agreeing with that proposal due to the amount of work
it would take to do that review.  Thank you, Paul!  I think it will be
less confusing for this RFC to use the same definitions as most others
these days are, even if the degree of the differences is arguable.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>