Re: ACTION-295: Should v. Must

(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