Hi,
I think there are far too many debates on RFC2119 semantics and I think
it can be reduced by focusing on better technical protocol writing
skills. A simple recommendation to always include (if possible) a
Minimum Requirements table or section can go a long way in removing
ambiguity. Some of these docs are just too verbose and design concepts
too spread out to extract all that is needed. Too easy to have semantic
conflicts. Things are missed or fall thru the crack.
It should be possible to have an automated RFC parser that pulls and
extracts the minimum protocol framework configuration. Its been done
since the 80s with automated configuration/fitting tools. It can be
done with IETF protocols as well, perhaps if only to extract a minimum
requirements table.
Personally, I think RECOMMENDED is closer to a SHOULD than MAY. IMV, a
SHOULD is a RECOMMENDED, yet still OPTIONAL mode of operation. So I
agree the term RECOMMENDED can be used to inform readers what is the
preferred mode of operation. I personally view it as a DEFAULT ON
condition where it is programmed for local policy to decide, but it is
ON out of the box because of the RECOMMENDED mode of operation. A MAY
on the other hand is also possible recommendation, but I see it as a
DEFAULT OFF or ON condition.
[o] SHOULD OPTION
[_] MAY OPTION
None of this is concrete of cause, but it should be easier if authors
were better skilled in writing more precise technical requirements
outlines to reduce the ambiguity and debates.
--
HLS
On 6/22/2013 1:28 PM, Barry Leiba wrote:
I believe that it would be wise to discourage
"RECOMMENDED" and "NOT RECOMMENDED" as synonyms for "SHOULD" and
"SHOULD NOT" unless they are clearly necessary to avoid awkward
sentences and the non-A/S intent is completely clear.
A fine suggestion, with which I agree.
Barry