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

Koen Holtman writes:
    
    Generic editorial warning: I seem to remember (though I don't know
    where I learnt it) that notes in an RFC are always non-normative by
    convention, so there should be no MMS terminology in them.  Jeff's
    corrections seem to take the opposite view, whereas Scott makes
    judgment calls on a note by note basis.  I don't have a direct
    connection to any RFC repository now so I can't check whether there
    are generic conventions with respect to notes, but somebody should
    check this.

It has indeed been our policy to avoid normative statements in
"Notes".  I basically followed this policy, although there are
a few places where it seemed like a secondary priority.  Also,
there are place where it's not clear whether a paragraph is
really a "Note" or not.  In almost every case, I did point out
that the Note in question contained apparently normative
language.  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.

MMS_AUDIT_ITEM_008:
	The paragraph starts with the word "Note", but it's not
	indented like the other "Notes".  The content is clearly
	normative, but it might just be restating other normative
	language.

MMS_AUDIT_ITEM_010:
	An actual "Note"; I changed a "should" (ambiguous) to
	an "ought" (non-normative).

issue MMS_AUDIT_ITEM_013
	I pointed out that this is a case where normative
	language appears in a Note, and it's not clear whether
	it was meant to be normative or not.  Someone with
	an interest should comment on the substance, not just
	the form.

issue MMS_AUDIT_ITEM_018:
	Definitely in a Note, but also possibly an
	interoperability requirement.  Again, review by
	a qualified person would be helpful.

issue MMS_AUDIT_ITEM_024:
	A Note that restates a normative requirement.

issue MMS_AUDIT_ITEM_062:
	I removed a "should not" from a Note.

issue MMS_AUDIT_ITEM_065:
issue MMS_AUDIT_ITEM_066:
	Notes that contain what appear to be normative
	requirements (aids to interoperability)

issue MMS_AUDIT_ITEM_075:
issue MMS_AUDIT_ITEM_104:
	I removed two "mays" from each of these Notes.

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."  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.

    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.  The right solution is to either define a general
"common form", or make it clear which specific "common forms" are
intended.  I tried to do the latter.

    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).

    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.

Using a word like "will" sidesteps the issue of whether this
is a conditional or unconditional requirement.  Which points
out that since I didn't look at the following text as carefully
as you have, where it says
  
  Some HTTP methods MUST cause a cache to invalidate an entity.

it seems (by my argument re: MMS 117) that these SHOULDS really
need to be MUSTs (or that the latter MUST has to be a SHOULD).

Otherwise, we're in the position of saying that doing something
is an absolute requirement of the specification, but doing it
according to our definition is only a conditional requirement.
I.e., the implementor has to do something, but is allowed (for
good cause) to ignore our specification of what that something is.
So this is probably a bug in the language, and needs to be resolved.

-Jeff

Received on Thursday, 6 August 1998 10:44:06 UTC