W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

transparency, SHOULD and MUST

From: Larry Masinter <masinter@parc.xerox.com>
Date: Tue, 27 Feb 1996 20:50:34 PST
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <96Feb27.205044pst.2733@golden.parc.xerox.com>
My reading on this issue is that we're converging on a position but
the wording needs to be careful, not because of how the normal
operation of the protocol will be but because we want to 'language
lawyer' exactly what is and isn't 'compliant' behavior.

I think this is OK, but I have a proposal for a procedural tactic:

Standards define compliance (or at least they can). Some
implementations ignore the standard. Should the standard say "this
standard might be ignored"? Should the standard not try to make
non-compliant behavior that some implementors would be tempted to

I've seen too many cases of standards groups foundering on this
conundrum. (I've worked on standards for a long time.) In the end,
it's hard to predict. We will say. They will do. Who can tell?

The working group as a whole and individuals at different times seem
to have different opinions about how strict to be for different
things.  You SHOULD'T use unregistered MIME types. Or you MAY use
them? Or you MUST implement UNLESS, but you SHOULD implement UPGRADE.
You SHOULDN'T ignore max-age but you MUST warn if you do.

I suppose what's difficult is that if we change a MUST to a SHOULD, we
might want to add another MUST that's the fallback if you DON'T. This
is how we got "vary" headers as well as URI (since we changed MUST
return URI list to SHOULD and then MUST indicate vary if you DON'T).
You SHOULD obey max-age but if you don't you MUST signal.

What I'm wondering is if we can declare a brief truce on these issues.
For a few weeks.  Not because they aren't important, but because we
have lots else to do, and SHOULD/MUST is hard to do consistently one
at a time.  It makes us try to game the system instead of engineer a
protocol: ("If we get the standard to say MUST instead of SHOULD then
when those turkeys run a proxy broadcast service I can say they're in
VIOLATION of the spec!")

I think what we'll need to do ultimately is to have some folks go
through the entire spec and look at every MUST and ask "what happens
if they don't"? And see if we want a fallback. Similarly, look at
every SHOULD and see if the protocol gets simpler if it turns into a
MUST, and whether we want to do that.

What do you think? SHOULD we do this? It might help us get through the
long list of issues more quickly if it isn't something that we MUST
deal with now.
Received on Tuesday, 27 February 1996 20:52:41 UTC

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