Re: ACTION-295: Should v. Must

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