Re: ACTION-295: Should v. Must

John,

I believe you've misread my intent. I am not looking for opportunities 
to "push the envelope." I am looking to avoid unintended consequences 
and provide certainty for the good actors. DNT will not solve the 
problem of bad actors or others who push the envelope.

-David

On 10/19/12 5:22 PM, John Simpson wrote:
> 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 <http://www.ConsumerWatchdog.org>
> john@consumerwatchdog.org <mailto: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 
>>> <http://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
>>>
>>>
>>
>