W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2014

Re: Removal of the note about extensions

From: Mitar <mmitar@gmail.com>
Date: Sat, 1 Mar 2014 15:45:48 -0800
Message-ID: <CAKLmikOYn9a8P7bVnhkSrAtDTA3boJJyY6NRMLc9oKK-dOsU2Q@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC