- From: Mitar <mmitar@gmail.com>
- Date: Mon, 24 Feb 2014 22:39:37 -0800
- To: Mike West <mkwst@chromium.org>
- Cc: Glenn Adams <glenn@skynav.com>, Mike Pomax Kamermans <pomax@nihongoresources.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi! > With this in mind, I'm inclined to add a non-normative note to the spec > along the lines of "Note that user agents are encouraged to allow > third-party add-ons and JavaScript bookmarklets to bypass policy > enforcement, either implicitly or based on the user's preference." Why reinventing the wheel? RFC 2119 here what SHOULD NOT in original note mean: "Enforcing a policy SHOULD NOT interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets." 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." In this sens this directly addresses Cox objections: if there valid reasons (compromised extensions, user preference, liability reasons, special UAs (kiosk mode)) UAs are allowed to interfere with the operation, but UAs have to understand the consequences. Personally, I would have there MUST NOT, but I agree that there are use cases, as explained by Cox, where UAs should behave differently. So I think SHOULD NOT is a very good compromise here, already covering what Cox is pointing out. I do not understand what is a problem with SHOULD NOT terminology? It is already a widely established terminology. I think that starting to use terminology like "encouraged" will introduce more issues interpreting it. RFC 2119 does not have "encouraged". Furthermore, just leaving previous note in means that there is less things which will change between 1.0 and 1.1. https://www.ietf.org/rfc/rfc2119.txt Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m
Received on Tuesday, 25 February 2014 06:40:05 UTC