W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

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

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Thu, 06 Aug 98 10:42:28 MDT
Message-Id: <9808061742.AA27475@acetes.pa.dec.com>
To: http-wg@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/305
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.

	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

	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

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.

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC