Re: ACTION-295: Should v. Must

On Oct 17, 2012, at 1:10 PM, David Wainberg wrote:

> Hi all,
> 
> From our call today, it seemed as if we are agreed that SHOULD=MUST.

No.

> If that's the case, let's replace all the SHOULDs with MUSTs in order to avoid ambiguity. Otherwise, if we use both, the intent is ambiguous and implementers will be confused and sad.

No.

> If it is not the case that we view them as equivalent, then as Berin suggested, we must get clear on what is our intent when using a SHOULD instead of a MUST. Despite the emphatic statements on the call today that it's perfectly clear, it is not so.

They are defined terms.

> From http://www.ietf.org/rfc/rfc2119.txt, these are the definitions of MUST and SHOULD:
> MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>    definition is an absolute requirement of the specification.
> 
> SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.

Yes, those are the definitions of those terms as we use them.

> There is obviously quite a difference between these two. I understand how the difference makes sense in a technical specification. However, for lawyers who will be interpreting the compliance specification, this is guaranteed heartache.

No.  They are defined terms.  Lawyers know what that means.

We are talking about the definitions that are the basis of over
a thousand core specifications for the Internet.  If any lawyer
has a problem with that, fire them.  Their opinions on the matter
are not relevant to our work, nor are the definitions going to
change, regardless of the opinions in this working group.

There are times when specifications incorrectly use the defined
terms where some other choice of words would be more appropriate.
If anyone is aware of such a case in the TPWG specifications, then
please highlight the questionable requirement(s).  We can then have
a specific discussion about what is being required, instead of a
meta-discussion about the defined terminology for requirements.

> What are "valid reasons in particular circumstances to ignore" part of the compliance specification? Contractual requirements? Cost? Breaks our business model? Don't feel like it? Does this translate to a reasonableness standard? In other words, does it mean that for a SHOULD requirement, an implementer must do it if it is reasonable to do so, but may ignore it otherwise? Does that not apply to the whole standard? Or do we mean that MUSTs must be done whether reasonable or not? If something in the spec is unreasonable, then why is it in the spec?

The defined terms highlight voluntary interoperability requirements.
In a compliance context, that would be requirements on clients
to ensure the syntax and semantics are faithfully represented when
sending DNT and requirements on servers that help them be consistent
with the user's expectations expressed by the DNT semantics.  And,
vice versa for the response tracking status resources, representations,
and Tk header fields.

Failure to adhere to a MUST requirement will break interoperability.
Failure to adhere to a SHOULD requirement might break interoperability,
but that brokenness might be less important than flexibility.
In general, SHOULD is used when there is a known preference
for a specific course of action, but some participants are
unwilling to do that and we have determined that the system won't
break as a result, even though we agree the result is less good.

None of the requirements are compulsory, since that is obviously
outside the scope of a voluntary standard. That does not prevent a
company from making statements that create an obligation to comply,
nor does it prevent legislators from writing laws that make it illegal
if some entity fails to comply.  These are not our problems to solve.

I honestly don't give a rat's ass whether a lawyer might question
a requirement one way or the other.  Compliance is still a technical
spec, requires significant technical understanding to make any sense
of the requirements regardless of the all-caps terms, and won't be
implemented by non-implementers.  If such a thing were ever to be
discussed in a judicial case, the sides would ask technical experts to
explain what the requirements mean, and we can only hope that those
experts can read.  If such a thing were debated in a legislative
context, I'd be overjoyed if the substance of the debate ever reached
the level of reviewing actual text in our specifications.

....Roy