W3C home > Mailing lists > Public > public-tracking@w3.org > October 2012

Re: ACTION-295: Should v. Must

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 18 Oct 2012 15:47:10 -0700
Cc: "public-tracking@w3.org" <public-tracking@w3.org>
Message-Id: <BC83F52F-3AF9-45AB-A4EC-FB93E4C75F1C@gbiv.com>
To: David Wainberg <david@networkadvertising.org>
On Oct 18, 2012, at 7:03 AM, David Wainberg wrote:

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

No, it simply doesn't matter to me.  The terms are appropriate for
anyone reading the document because they do correspond to the actual
English meaning of the terms.  They were formalized not because the
technical folks needed a new meaning, but rather because the
technical folks tend to be less versed on the exact purpose of
using those words than some other audiences (including lawyers)
and because the patent lawyers participating in and around the IETF
have a distinct preference for defined terms.

In other words, RFC2119 exists because technical folks often use
those terms in a way that lawyers would consider insufficiently
motivated.  The purpose of highlighting them in all-caps and giving
them a specific meaning is to prevent the technical folks from
using "should" in a way that does not express a requirement
that the protocol needs to interoperate with other implementations.

That is why, when Berin cautioned that a group of regulators or
legislators or a judicial process would interpret these words
more forcefully, our response was that they are INTENDED to be
interpreted forcefully -- they are requirements of the protocol.
That is why we have a normative reference to RFC2119.

That does not mean there is no difference between MUST and SHOULD
or no difference between SHOULD and MAY.  They have obvious
differences, which you seem to understand without problem, even
before looking at the RFC2119 definitions.

Regardless, RFC2119 is not only "out of scope" for this working group,
it isn't even controlled by the W3C.  If your suggestion is that
the definitions need to be changed, feel free to join the IETF.
If your suggestion is that lawyers can't sufficiently find the
definitions or understand the distinctions within them, then all
evidence of that is against you.  If your suggestion is that we
are using them incorrectly in some sentences within the specifications,
then please point out those sentences for correction.

Editors, please note that the all-caps is only for highlighting
the words so that requirements are easily found -- all usage
of those words, whether in caps or not, is subject to RFC2119.

> 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.

Fine.  I have answered that misunderstanding, several times over.

>>> 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. 

I have not misunderstood them.  You have not either -- you are just
belaboring a point as if this were a debate class. Apparently, some
unnamed future readers might somehow be capable of misunderstanding
them.  I don't care.  Enough people in this working group do understand
the distinctions that the end product will be reviewed accordingly.
In fact, I have already made many comments to that effect (regarding
the use of normative phrases in non-normative sections) that are
part of the pending editorial changes, I hope. [If not, I am fully
capable of pointing them out in the next review.]

I am quite certain that we need to carefully review the use of
should, may, must, and required in both documents, whether or
not they are in all-caps at the moment.  All specifications go
though that process, usually when they are relatively close
to being prose-complete.

>> 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.

That simply isn't relevant.  Technical specifications are usually
far more detailed than policy documents, since they rely less on
individual judgement.  Nevertheless, the meaning of the terms is
the same.

>>  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.

All of those sections could be removed from the specification and
not change the legally binding nature of the protocol.

As far as I can tell, the only reason we have those sections is
because members on both sides keep pointing out the obvious in
discussions, so the obvious answers got placed in actions, which
in turn got placed in the compliance document out of the bizarre
hope that maybe, just maybe, members of this working group will
stop pointing out the obvious if it is actually written in the spec.

Personally, I prefer brevity (I am a slow typist).  When companies
publish a document on a website that promises certain behavior,
I generally assume that they will be bound by those promises.
Likewise, I am fully capable of ignoring any requirement that assumes
compliance until such time as I choose to make that promise.

I know that nothing in our spec can override sovereign laws, even
if we wanted to, so I feel no need to point that out either.
I don't know why people keep bringing it up.  And I have never heard
of a standard that could be overridden by contract, even if the
participants chose to include that in the contract.

For that matter, I don't even understand why the W3C chose to
charter this group with a separate document for definitions
and compliance.  Clearly, whatever goal they had in mind, that
decision was utterly stupid.

>> 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.

Then we need to have specific discussion of the intent of specific
requirements.  The terms are already defined.

>>> 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. 

No, it is a conjecture, and one that cannot be solved.

It is impossible to write a document that meets the understanding
of some unknown people who have never read the document and most
likely never will.  It is impossible to evaluate when we have crossed
the threshold from "exact enough for us" and "exact enough for
everyone", nor is there ever any need to do so.  It is for exactly
that reason that we use SHOULD when it is neither necessary nor
possible to list all potential reasons that might lead an
implementation to choose not to implement a SHOULD requirement.
If it were possible to list all reasons, we would instead say
"MUST do so except under the following circumstances ...".

If conformance isn't desired (by all parties) for interoperability,
then it can't be phrased as a requirement.

If it is your intention for this group to solve unsolvable
problems before we can talk about the problems that
we have actually been chartered to address, then I am going to
shut you down, as will anyone who doesn't like their time being
wasted on diversions.

>> 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.

We have.  It is time to direct comments to actual language that can
appear (or should not appear) in the specifications, and that goes
for all of the irrelevant meta-discussions in and around the
Amsterdam F2F meeting.  If it's broke, raise an issue, offer a fix,
let the working group discuss and make a decision, and then choose,
based upon the end result of all such decisions as recorded in the
final WG documents, whether to implement the protocol or not.

There are plenty of problems with the existing documents that can
be solved by merely suggesting better text.

....Roy
Received on Thursday, 18 October 2012 22:47:37 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:36 UTC