Re: ACTION-295: Should v. Must

Maybe you're both right.  Roy is right that SHOULD and MUST have well-defined meanings as they're used in numerous standards documents.  And David is right that SHOULD can be problematic in a standard that will be read and applied by lawyers.  Fear about breaking the law will drive some lawyers to tell their companies that SHOULD = MUST.  Other lawyers will try to use SHOULDs as loopholes to avoid requirements their companies don't like.  Either way, the spirit of the SHOULD is lost.

Every time you use a standard ("unsafe speed") instead of a rule ("over 65 miles per hour"), you effectively delegate discretion to the decision-maker.  Sometimes that's important: 65 is way too fast in a snowstorm.  But sometimes it's problematic: the police may pull over only minorities.  So to the extent David and Roy disagree, it's about how to trade off not just flexibility versus clarity, but discretion for implementers versus distrust of lawyers.

James

--------------------------------------------------
James Grimmelmann              Professor of Law
New York Law School                 (212) 431-2864
185 West Broadway       james.grimmelmann@nyls.edu<mailto:james.grimmelmann@nyls.edu>
New York, NY 10013    http://james.grimmelmann.net

On 2012-10-18, at 10:03 AM, David Wainberg <david@networkadvertising.org<mailto:david@networkadvertising.org>> wrote:

(I always enjoy Roy's forceful missives when aimed at someone else. Not as fun when I'm the target :)

Hi Roy,

I have specific responses inline, but it seems we have a fundamental disagreement about the legal nature of the Policy and Compliance document.

On 10/17/12 6:06 PM, Roy T. Fielding wrote:
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.
Yes, this is what happened. You may disagree with the statement, but this is what several people stated in IRC. It was also said in Amsterdam. This is why I am harping on the issue. There remains misunderstanding about how we are using these terms.

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.
Regardless of whether or how they are defined, if we have misunderstood their meaning or effect, then our use of may not reflect our intent.

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.

Technical specifications, not "Policy and Compliance" specifications.

 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.
I'm a lawyer. Fire me. There are many lawyers participating in this working group. Our opinions as lawyers are relevant because we are writing a legal document -- one that asks companies to make legally binding representations and to suffer the consequences for acting inconsistent with those representations. There are provisions that require contractual relationships. There are provisions that require assessments of reasonableness. There are exceptions for legal requirements. I think you who proposed that the provision of the WKL resource should constitute a legally binding public commitment to honor DNT. It will be lawyers who decide, ultimately, when and how to implement DNT in their companies. If we do not take that into account, we guarantee failure.

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.
My point is that because members of the working group have had differing ideas about the meaning or effect of these terms, their usage in the specification may not reflect our actual intent. All I want is for us to agree on our intent and ensure that the terms we use reflect that intent.

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.

The problem remains of how implementers will view SHOULD. Is it merely a preference that can be ignored? On what basis can it be ignored? Technologists and lawyers will and do see this problem differently -- that's the problem we have.
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.
Rodents aside, you should care. Lawyers in companies will have a lot to say about whether or how this gets implemented. We need to take that into account.

 Compliance is still a technical
spec,
It's not. This is, I guess, a fundamental disagreement we have.

-David

Received on Thursday, 18 October 2012 14:26:22 UTC