- From: David Wainberg <david@networkadvertising.org>
- Date: Wed, 17 Oct 2012 16:10:37 -0400
- To: "public-tracking@w3.org" <public-tracking@w3.org>
- Message-ID: <507F10BD.8030201@networkadvertising.org>
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
Received on Wednesday, 17 October 2012 20:11:07 UTC