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

Re: ACTION-295: Should v. Must

From: Berin Szoka <bszoka@techfreedom.org>
Date: Wed, 17 Oct 2012 16:38:39 -0400
Message-ID: <CAEjRf9+T1m3spk-VtGkEHRJPOVgFMn-Xaw7BCiy0C4S_jWOH1A@mail.gmail.com>
To: David Wainberg <david@networkadvertising.org>
Cc: "public-tracking@w3.org" <public-tracking@w3.org>
Well said, David. I didn't want to press the point on the call today (over
the jeers of those on IRC who thought this was clear), but I was going to
say something similar.

No lawyer would ever have written these definitions—or at least, would
assume that they suffice in a context as contentious as this one.  Like
David, I understand the words here, but not how they will actually be
applied in the real world.  The definition seems to put the burden on the
party choosing not to do what "should" be done to explain its decision, but
that's it.  Is the party supposed to document its "understanding" of the
"full implications" of its decision, and how it has "carefully weighed" the
"different course" chosen?  Who will judge that decision?  Under what
standard?

The point David, Shane and I have been trying to make is that, without
further clarification on these rather important questions, the highly
contentious* policy *issues governed (yes, governed) by every aspect of our
spec that uses the word "should" will tend to be resolved by lawyers
advising their clients that this issue is awfully murky, involving
significant litigation and political risks and the client should simply
read "should" as "must."

I'd love to hear from the other lawyers in this working group on this
point.  Counselors?

On Wed, Oct 17, 2012 at 4:10 PM, David Wainberg <
david@networkadvertising.org> wrote:

>  Hi all,
>
> From our call today, it seemed as if we are agreed that SHOULD=MUST. 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.
>
> 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.
>
> From http://www.ietf.org/rfc/rfc2119.txt, these are the definitions of
> MUST and SHOULD:
>
>
> MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>    definition is an absolute requirement of the specification.
>
> SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
>
>  There is obviously quite a difference between these two. I understand
> how the difference makes sense in a technical specification. However, for
> lawyers who will be interpreting the compliance specification, this is
> guaranteed heartache. 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?
>
> Best,
>
> David
>
>
>
>
>


-- 
Berin Szoka | President, TechFreedom | @TechFreedom
bszoka@techfreedom.org | @BerinSzoka
Received on Wednesday, 17 October 2012 20:39:28 UTC

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