Re: suggested revision for MUST/SHOULD

[DRUMS WG Chair <[e-mail]>]

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 <[e-mail]> 
wrote:
> 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
>