1. Bugs may be present in the CSP design which require future
compatibility breakage.  These obviously cannot be foreseen and, though
we desire it, we can't guarantee forward compatibility.

2. New types of content (per your example) or new web APIs may be added
in the future which don't shoehorn nicely into one of our current policy
buckets.  If we have to add another policy directive in the future, then
it will violate the policy syntax in older versions which will cause
them to fail closed (according to the current design).

3. We arguably want to have a pref for users to turn off CSP (for
testing or otherwise).  It would be useful to have the version number
available as a means to communicate to the site that, even though the
client supports CSP by default, CSP has been disabled on this client.

I looked at each of the HTTP Header Field Definitions and my preference
for communicating the CSP version is to add a product token [1] to the
User-Agent [2] string.  This would add only a few bytes to the U-A and
it saves us the trouble of having to go through IETF processes of
creating a new request header.

Thoughts?

-Brandon

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.8
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43