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

There has been no comments on Jeff and Scott's massive audit.  I suspect 
everyone who has looked at them has had their eyes glaze over; I know 
I have.  But driving the keyboard means I actually had to pay attention 
to all of the diffs (all 222 of them!). I noted a few problems.  All, in 
all, I think they did a great job. I encourage other brave hearted people
to review their work as well.

Here's what I noted of significance that differs from their recommendation:

MMS 023:
Message bodies are often NOT optional in the protocol (they may in fact
be required for certain responses), so the use of optional in this
context is confusing. So turning optional into OPTIONAL is clearly
wrong, as it may not be optional. I said "possibly a message body" to
remove the confusion.

MMS 036:

This is really a SHOULD requirement that the client may presume unless
otherwise told in the specification that connections persist: and I added
a clarification: "even after error responses from the server.", as for
evolution's sake, it is important that you be able to deliberatly try
something that will return an error, and then continue.  This may
cost a round trip, but at least avoids another TCP connection, which
history has shown can generate major problems. So it reads:

"That is, unless otherwise indicated, the client SHOULD assume that the 
server will maintain a persistent connection, even after error responses 
from the server."

This also provides clarification for Art Goldberg.

MMS 144:
"Users MAY" doesn't make sense, and can't be normative; we have no
control over people's behavior.

MMS 168:
Scott's comments are probably correct, that this is so stupid as not
to be worth being in the spec. As I remember, it was to quell
people who were afraid there would be some requirement to implement
multipart range requests, pointing out that if they don't ask
for them, they won't get them in return.

But for now, it is... 
However:
"should not" -> "MUST NOT"; if a client is stupid enough to ask for
a multipart byte range and can't understand it, it will in fact cause
him not to be able to understand the response, and lose in various ways.
So the should not should be a MUST NOT.

MMS 184:

I believe Scott is correct: this SHOULD should be a MUST.  If it is
left a SHOULD it would be inconsistent with the following MUST NOT and
MUST requiring correct behavior when Max-Forwards is being used.  If it
isn't a MUST, an implementation might still forward expired requests,
defeating the debugging purpose of Max-Forwards in the first place.

MMS 190:

I think Scott is wrong on this one.  The should->SHOULD is in text which 
is recommendations to developers (that they support ranges), not requirements 
on the implementation.  Putting a SHOULD into a clearly optional feature, 
when the previous sentence says it MAY be ingnored, is clearly wrong.

MMS 209:

The first should is really recommendation, and can't be normative as
"should be conservative in offering accept header configuration
options to end users" doesn't have any meaning that could be enforced.

The second should can be a SHOULD, as this warning is possible, and
what "which provide a high degree of header configurability" is left
to rational people (are implementer's rational? :-)) to decide.

MMS 219:

The should is NOT normative to our specification (it is normative in MHTML); 
it is just pointing out to implementers that they should be careful and 
should pay attention to the MHTML spec.  I reworded it to avoid the use 
of should. 

				- Jim

Received on Tuesday, 28 July 1998 11:23:38 UTC