Re: ACTION-295: Should v. Must

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

Received on Friday, 19 October 2012 20:43:59 UTC