- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Thu, 18 Oct 2012 15:47:10 -0700
- To: David Wainberg <david@networkadvertising.org>
- Cc: "public-tracking@w3.org" <public-tracking@w3.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