- From: Justin Brookman <justin@cdt.org>
- Date: Wed, 17 Oct 2012 17:34:55 -0400
- To: public-tracking@w3.org
- Message-ID: <507F247F.3050307@cdt.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