Re: ACTION-295: Should v. Must

Actually, I find only two occurrences in the document of 
capitalized/highlighted SHOULDs, in:

6.1.1.3 Reasonable Security
3.6.1 Option 1: Unlinkable Data

The rest, and there are many, are all lower case. Do we mean all of 
these small-case shoulds to be truly, 100%, no-questions-asked optional?

On 10/17/12 5:34 PM, Justin Brookman wrote:
> 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
>>>>
>>>
>>
>