Skip to content

Commit

Permalink
IANA: second pass over the XML file.
Browse files Browse the repository at this point in the history
  • Loading branch information
@mikewest
mikewest committed Jan 27, 2016
1 parent 1bfbb97 commit 829278b
Showing 1 changed file with 24 additions and 34 deletions.
58 changes: 24 additions & 34 deletions iana/rfc7762.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5226 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC5234 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC5341 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5341.xml">
Expand Down Expand Up @@ -36,11 +37,8 @@

<date month="January" year="2016"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on http://www.rfc-editor.org/search.
-->

<keyword>example</keyword>
<keyword>CSP</keyword>
<keyword>W3C</keyword>

<abstract>

Expand All @@ -62,26 +60,33 @@ directives defined in the Content Security Policy Level 2 specification.</t>
<section anchor="introduction" title="Introduction">

<t>The Content Security Policy (CSP) specification <xref target="CSP"/>
defines a mechanism by that web developers can control the resources which a
particular page can fetch or execute, as well as a number of security-relevant
policy decisions.</t>
defines a mechanism that web developers can use to control the resources which a
particular page can fetch or execute, as well as a number of additional
security-relevant policy decisions.</t>

<t>The policy language specified in that document consists of an extensible set
of "directives", each of which controls a specific resource type or policy
decision. This specification establishes a registry to ensure that extensions
to CSP are listed and standardized.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be
interpreted as described in <xref target="RFC2119"/>.</t>

</section>
<section anchor="use-of-the-registry" title="Use of the Registry">

<t>Content Security Policy directives must be documented in a readily available
public specification in order to be registered by IANA. This documentation must
public specification in order to be registered by IANA. This documentation MUST
fully explain the syntax, intended usage, and semantics of the directive. The
intent of this requirement is to assure interoperable independent
implementations, and to prevent accidental namespace collisions between
implementations of dissimilar features.</t>

<t>Documents defining new Content Security Policy directives must register them
<t>Documents defining new Content Security Policy directives MUST register them
with IANA, as described in Section 3. The IANA registration policy for such
parameters is "Specification Required" <xref target="RFC5226"/> and is further
discussed in Section 3.2.</t>
Expand All @@ -94,11 +99,11 @@ Policy Directives".</t>

<section anchor="content-security-policy-directives-registry" title="Content Security Policy Directives Registry">

<t>New Content Security Policy directives, and updates to existing directives, must
<t>New Content Security Policy directives, and updates to existing directives, MUST
be registered with IANA.</t>

<t>When registering a new Content Security Policy directive, the following
information must be provided:</t>
information MUST be provided:</t>

<t><list style="symbols">
<t>The directive's name, an ASCII string conforming to the <spanx style="verb">directive-name</spanx>
Expand Down Expand Up @@ -158,36 +163,20 @@ Required" <xref target="RFC5226"/>, which uses a designated expert to review the
specification.</t>

<t>When appointing an Expert (or Experts), the IESG SHOULD draw from the W3C's
security community, coordinating through the liaison.
<!-- [rfced] Is the use of "SHOULD" in all capital letters used as defined in
RFC 2119? If yes, we will include a normative reference to RFC 2119 and add
the keywords paragraph to the introduction (see below).
Original:
When appointing an Expert (or Experts), the IESG SHOULD draw from the
W3C's security community, coordinating through the liaison.
Keywords paragraph defined in RFC 2119:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
-->
</t>
security community, coordinating through the liaison.</t>

<t>The designated expert, when deliberating on whether to include a new directive
in the registry, should consider the following criteria. This is not an
in the registry, SHOULD consider the following criteria. This is not an
exhaustive list, but representative of the issues to consider when rendering a
decision:</t>

<t><list style="symbols">
<t>Content Security Policy is a restrictive feature, which allows web developers
to deny themselves access to resources and APIs that would otherwise be
available. Deploying Content Security Policy is, therefore, a strict reduction
in risk. The expert should carefully consider whether proposed directives
in risk. The expert SHOULD carefully consider whether proposed directives
would violate this property.</t>
<t>Granular directives are valuable, but the expert should strive to strike a
<t>Granular directives are valuable, but the expert SHOULD strive to strike a
reasonable balance between providing developers with all the knobs and
switches possible and providing only those with known security implications.</t>
</list></t>
Expand All @@ -198,8 +187,8 @@ switches possible and providing only those with known security implications.</t>

<t>The registry in this document does not in itself have security implications. The
directives specified, however, certainly do. The documents referenced when
registering new directives must contain detailed security and privacy
considerations sections, and should contain usage information that informs web
registering new directives MUST contain detailed security and privacy
considerations sections, and SHOULD contain usage information that informs web
developers as to the directive's expected implementation.</t>

</section>
Expand Down Expand Up @@ -230,6 +219,7 @@ developers as to the directive's expected implementation.</t>
appears on
http://xml2rfc.ietf.org/public/rfc/bibxml4/reference.W3C.CR-CSP2-20150721.xml
-->
&RFC2119;
&RFC5226;
&RFC5234;

Expand Down

0 comments on commit 829278b

Please sign in to comment.