suggested revision for MUST/SHOULD

[Keith Moore <[e-mail]>]

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