Re: MUST-MAY-SHOULD (MMS) audit...

Jeffrey Mogul:
>
[....]
> In almost every case, I did point out
>that the Note in question contained apparently normative
>language.

Usually this apparently normative language merely explains or restates
actual normative language in the main text.  I recall that at least
one editor (Roy?) had the policy of stating all normative requirements
exactly once, in order to reduce the risks of
self-contradictions. This policy leads to the editorial device of
using a note whenever you want to explain or restate requirements
already stated once.

>  I didn't want to delete requirements simply because
>they appeared in Notes, but I also didn't want to spend the
>time to rewrite large chunks of text.

Whenever reviewing a note in the past I have always kept in mind that
it could not contain a normative requirement, so I am pretty sure that
the set of the requirements in the draft won't change if we leave all
notes non-normative.

[...]
>In other words, I'm not sure why Koen thinks that I "took an
>opposite view" rather than making "judgement calls on a note
>by note basis."  

Just an overall impression I got.  I may have missed some exceptions.

>Nevertheless, if we really want to be consistent
>on this formality, then someone should spend some effort
>splitting some of these Notes into normative and true-Note parts.

I believe being consistent on this is very necessary, so I would like
one of the editors to take the effort.

>    MMS 025: I am not sure if Jeff is right in his assumption as to
>    what the term "common form" is supposed to mean.  Maybe "common
>    form" means `not extended over multiple lines' here.
>
>As I wrote, we don't have a definition for "common form" in general, so
>we can argue until the end of the millenium about what this paragraph
>actually means. 

Hmm, I was hoping that the original author of that sentence, or maybe
someone knowledgeable of email/news header terminology, would come
forward and clarify.

[...]
>    MMS 117: The musts in the two items define conditions to be met for
>    a MAY to apply, so they should be lowercase (or preferably
>    rephrased), not uppercase.
>
>I think your logic is faulty.  An analogy: in this sentence,
>
>	You MAY pilot an airliner, but in order to do so, you
>	MUST have a pilot's license.
>
>it is pretty clear that the phrase "you MUST have a pilot's
>license" does not apply to everyone; it only applies to pilots,
>but then it is an "absolute requirement of the specification"
>(to quote from RFC2119).  I think you are arguing that one should
>instead say
>
>	You MAY pilot an airliner, but in order to do so, you
>	ought to have a pilot's license.
>
>which has a very different meaning (and one that would convince
>me to travel by train).

No, I am arguing that you should say

  If you have a pilot's license you MAY pilot an airliner.

which avoids the whole problem.  Compare this to the following piece
of text from the spec:

       If the response includes the "must-revalidate" Cache-Control
       directive, the cache MAY use that response in replying to a
       subsequent request.

The logical structure of such things is

  if 'condition' then ( 'subject' MAY 'action' )

My sense of grammar tells me that the 'condition' part, if it includes
the verbs must, may, or should, should never have these capitialised
as keywords, because in the condition parts these verbs do not signal
an actual requirement on a subject in the sense of rfc2219.  I got
most of my grammatical intuition from reading Latin and writing C, so
I may be wrong, but I don't think so.

>    MMS 125: in the definition of "invalidate an entity", the two
>    shoulds are defining a term, they are are not keywords specifying a
>    requirement, so they should be rephrased, e.g. from `should' to
>    `will'.
>
>I believe that this language basically defines a "subroutine"
>rather than simply a "term".  It's giving a specific meaning to a
>verb-phrase when that phrase is used in this specification.

Well, I agree that this could be a "subroutine" too, but as you also
note, this does not solve the problem in the spec, so we should fix
this one way or the other.

>-Jeff

Koen.

Received on Monday, 10 August 1998 02:52:05 UTC