Re: ACTION-295: Should v. Must

David,

I've been watching this discussion from afar because I believe that the RFC2119 definitions are about as clear as can be. But I think I've got a new insight into the issue and want share it . You seem to most worried about the possibility of a company deciding not to follow the spec because it's only a SHOULD and then having that come back to bite them.

Put another way, you seem to be of the mind set that companies will look to ignore the standard as much as they can and SHOULD provides a means to do that.

Instead, I'd suggest that good actors will be looking for ways to comply with the spec rather than evade it and will have no problem doing what SHOULD be done.

In the newspaper business there was an old editors rule: "When in doubt, take it out."  I'd suggest a similar approach here. Companies ought to err on the side of caution: When in doubt about what's required, take the most privacy friendly approach.

That will win consumers' trust and be good for business in the long run.

If on the other hand, a company wants to push the envelope and constantly seek ways to game the spec claiming it only says we SHOULD do something not that we MUST, well, it deserves what it gets when it plays fast and loose what it SHOULD do.

Cheers,
John

----------
John M. Simpson
Consumer Advocate
Consumer Watchdog
2701 Ocean Park Blvd., Suite 112
Santa Monica, CA,90405
Tel: 310-392-7041
Cell: 310-292-1902
www.ConsumerWatchdog.org
john@consumerwatchdog.org

On Oct 19, 2012, at 1:43 PM, David Wainberg wrote:

> Walter,
> 
> This is a very good analysis. I have two lingering concerns, however. First, companies will have absolutely no guidance, precedent, etc. to inform them what is a legitimate "pressing need" or a "corner case" that justifies their decisions, so no way to evaluate the risk of making a decision.
> 
> Second, the damage is done long before a case gets to court, if it even does. A newspaper article or an investigation made public will do serious harm to a company if the accusation is that they made the wrong decision. Vindication in court, if it ever comes, may be almost worthless. Even vindication in the press isn't worth much after the damage has already been done. This will make companies quite inhibited about being innovative, even in cases where it was not the intent of the working group to limit their particular case.
> 
> In any case, I am finding this conversation helpful, and I will review the compliance doc in light of the discussion we have had on this thread.
> 
> -David
> 
> 
> On 10/19/12 2:50 PM, Walter van Holst wrote:
>> On 10/19/12 4:22 PM, David Wainberg wrote:
>>> Hi Walter,
>>> 
>>> You are a lawyer, yes? I have not had the opportunity to try to
>>> interpret the definitions of RFC2119 in a legal context. Can you explain
>>> how you have counseled clients when implementing a SHOULD provision of a
>>> standard where there is legal liability attached? Do have any examples
>>> of bases under which you have felt comfortable counseling a client that
>>> they can ignore a SHOULD requirement?
>> Dear David,
>> 
>> I do not practice law outside the Netherlands and even there I do not
>> represent anyone in court. Moreover, I am invited because of my
>> involvement with civil society (Vrijschrift.org), I am not participating
>> in my professional quality of a legal consultant.
>> 
>> Having said that, if a client were to ask me about RFC2119 or if I were
>> to assist an attorney in a case about RFC2119, I would feel rather
>> comfortable to counsel such client or to have such an attorney argue
>> that the SHOULD requirement can be ignored if there is a pressing need
>> to do so.
>> 
>> Basically, in most civil law jurisdictions (and I've been told several
>> times by people qualified to practice in common law jurisdictions that
>> the picture in those jurisdictions is not fundamentally different) the
>> 'customs of a trade' weigh heavily when interpreting for example a
>> contract. This standard may be construed as a contractual obligation in
>> the future to which a similar interpretative framework would be applied.
>> 
>> As such, in any court case it would be relatively straightforward to get
>> someone like Roy to the witness stand and explain to a judge that SHOULD
>> is close to, but not entirely the same as, MUST. And that any deviations
>> from the standard put a burden of proof on the deviating party that the
>> circumstances justify such a deviation. Basically my advice would be
>> that violation of a MUST requirement is an objective violation of the
>> standard and that it will be exceedingly difficult to argue that the
>> deviating party nonetheless was in compliance. Whereas a SHOULD
>> requirement allows for corner cases in which a deviation is presumed to
>> be in violation of the standard but in corner cases this nonetheless can
>> be justified.
>> 
>> At the end of the day it is not that difficult. MUST means compliance at
>> _all_ times, SHOULD allows for non-compliance when this would result in
>> patently ridiculous situations. I know that common sense is not that
>> common, especially not among lawyers, but that is what it boils down to
>> eventually.
>> 
>> By invoking RFC2119 we're invoking interpretation of the DNT standard
>> through the prism of web standardisation engineers. Which given the
>> nature of any W3C standard is the right prism to me. This ultimately is
>> a technical standard and regardless of the policy implications I think
>> it should be interpreted from a technical perspective first. I know that
>> lawyers tend not to enjoy having to take the back seat to engineers, but
>> this is where they belong here.
>> 
>> Regards,
>> 
>>  Walter
>> 
>> 
>