- From: Mitar <mmitar@gmail.com>
- Date: Sat, 1 Mar 2014 15:45:48 -0800
- To: Mike West <mkwst@google.com>
- Cc: Glenn Adams <glenn@skynav.com>, Mike Pomax Kamermans <pomax@nihongoresources.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi! On Tue, Feb 25, 2014 at 2:35 AM, Mike West <mkwst@google.com> wrote: > I noted my justification further down in the email you're quoting: normative > claims and vendor-specific behavior don't mix well. That's why I'd rephrase > the original normative claim as a non-normative note, making the WG's > consensus clear to implementers and authors, while not placing compatibility > obligations on inherently incompatible features. I must admit I do not understand very well the meaning of "normative" in this case. I thought that SHOULD as defined in RFC 2119 is not really a normative claim? I must say that I understand that maybe people not familiar with SHOULD definition would understand the sentence much more normative than those who have read the definition, but on the other hand I do not see that it is really useful to introduce new imprecisely defined words as "encouraged". > Cox, if I understand Glenn, correctly, objects strenuously to anything that > implies a positive obligation to allow extensions, add-ons, bookmarklets, > etc. to bypass CSP. "may" is fine, "should" is not, as far as that objection > is concerned. But if we compare MAY with SHOULD NOT: SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) I am not sure if W3C consensus is that not blocking extensions is truly optional and vendors can choose whatever they want without any reason, but that it is more something which should not be done, while understanding that there are situations where blocking is OK. SHOULD NOT reflects this well. MAY states that any behavior is OK, while SHOULD explains which one is preferred, but allows for exceptions. Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m
Received on Saturday, 1 March 2014 23:46:15 UTC