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

Re: ACTION-295: Should v. Must

From: Justin Brookman <justin@cdt.org>
Date: Wed, 17 Oct 2012 17:34:55 -0400
Message-ID: <507F247F.3050307@cdt.org>
To: public-tracking@w3.org
If there are any SHOULDs you want (re)evaluated given the W3C definition 
of SHOULD, please share them with the group.

Justin Brookman
Director, Consumer Privacy
Center for Democracy & Technology
1634 I Street NW, Suite 1100
Washington, DC 20006
tel 202.407.8812
fax 202.637.0969
justin@cdt.org
http://www.cdt.org
@CenDemTech
@JustinBrookman

On 10/17/2012 5:25 PM, David Wainberg wrote:
> Lauren,
>
> There are actually two sides to this issue. One is what we're talking 
> about explicitly in this thread: that implementers will be confused. 
> The other side we've perhaps not been clear about, and that is the 
> working group's intent. We've sometimes fallen back on SHOULDs as 
> softer requirements -- compromise positions when the group cannot 
> agree on a MUST. So the point really is that, if SHOULDs and MUSTs are 
> equivalent, then those cases are not compromises at all. And if that's 
> the case, then the group needs to (re)evaluate every single SHOULD 
> provision as if it is a MUST. Alternatively, if we really do intend 
> the SHOULDs to be softer, then we must provide guidance on what 
> standard should be applied when deciding.
>
> -David
>
> On 10/17/12 5:11 PM, Lauren Gelman wrote:
>>
>> Sorry I missed the call.
>>
>> Of course it would be much easier if you made all these 
>> Shoulds--Musts and I strongly support that if there if David and 
>> Shane are on-board.  However I had thought that for the past year I 
>> have followed this Shane was the one who wanted to change all the 
>> musts--> shoulds in order to "get more companies to sign on."  Which 
>> creates grey areas, which, like everything else in life as well as 
>> regulations, makes things murkier.
>>
>> But I think there is no more business risk in compliance with this 
>> than any other thing that lawyers advise clients on every day. Every 
>> single day I have companies ask me if they can do X and we look at 
>> law Y and figure it out.  Frequently, I ask other lawyers what they 
>> are doing or attend conferences about it and thus develops a 
>> framework for what is "reasonable" (There was, in fact, even briefly 
>> a subgroup of this group that was working on compliance. )  Some 
>> companies are more risk averse, some willing to take risks.  You will 
>> NEVER write that out of any legislation that is not going to become 
>> obsolete in 5 minutes.
>>
>> So I think, assuming in good faith that this is part of the 
>> discussion to move the process forward, you can assume that the 
>> lawyers and tech teams that want to "Go DNT:1" will muddle through 
>> and figure it out. Just write the spec that makes the most sense.
>>
>> Lauren Gelman
>> BlurryEdge Strategies
>> 415-627-8512
>>
>> On Oct 17, 2012, at 1:38 PM, Berin Szoka wrote:
>>
>>> 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 <mailto: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 <mailto:bszoka@techfreedom.org> | @BerinSzoka
>>>
>>
>
Received on Wednesday, 17 October 2012 21:35:24 UTC

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