specification language

Koen writes:
    I read the `should' in the spec to a bit weaker than `must', but not
    much weaker.  On a scale of recommendedness:
    
      must > should > strongly recommended > recommended > may
    
I suspect that Roy is following the meanings spelled out in RFC1122:

         *    "MUST"
              This word or the adjective "REQUIRED" means that the item
              is an absolute requirement of the specification.

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

         *    "MAY"
              This word or the adjective "OPTIONAL" means that this item
              is truly optional.  One vendor may choose to include the
              item because a particular marketplace requires it or
              because it enhances the product, for example; another
              vendor may omit the same item.

         An implementation is not compliant if it fails to satisfy one
         or more of the MUST requirements for the protocols it
         implements.  An implementation that satisfies all the MUST and
         all the SHOULD requirements for its protocols is said to be
         "unconditionally compliant"; one that satisfies all the MUST
         requirements but not all the SHOULD requirements for its
         protocols is said to be "conditionally compliant".

RFC1122, in other words, equates "recommended" with SHOULD.  Note
also that in RFC1122, when then mean "MUST" or "SHOULD" or "MAY"
in one of these senses, they capitalize the word to make it obvious.

    So I think that the `should' in the spec implies far less optionalness
    than Shel's `should' seems to do.  In particular, I read the spec's
    `should' to take precedence over all efficiency considerations:
    gaining efficiency (saving bandwidth) is not not a good enough reason
    to violate a `should'.

I would read SHOULD to mean "implementors should try really hard to
make their code work this way; system managers should not change this
part of the code without a really good reason."  In other words, if
a system manager knows that gaining efficiency is worth violating the
SHOULD, that's OK, but the default ought to be what the SHOULD asks for.

-Jeff

Received on Tuesday, 5 September 1995 16:21:23 UTC