diff --git a/index.bs b/index.bs
index 2209dac..5119804 100644
--- a/index.bs
+++ b/index.bs
@@ -36,7 +36,6 @@ spec: ABNF; urlPrefix: https://tools.ietf.org/html/rfc5234
     text: VCHAR; url: appendix-B.1
     text: WSP; url: appendix-B.1
 
-
 spec: Fetch; urlPrefix: https://fetch.spec.whatwg.org
   type: dfn
     text: fetch; url: concept-fetch
@@ -213,10 +212,7 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180
   specified in RFC5234. [[!ABNF]]
 
   <a href="https://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a> of
-  [[!ABNF]] defines <a>VCHAR</a> (printing characters).
-
-  <a>WSP</a> (white space) characters are defined in <a href="http://www.w3.org/TR/html5/infrastructure.html#space-character">Section 2.4.1 Common parser idioms</a> of the HTML 5 specification as
-  <code>White_Space characters</code>. [[!HTML5]]
+  [[!ABNF]] defines <a>VCHAR</a> (printing characters) and <a>WSP</a> (white space).
 
   </section>
 
@@ -247,8 +243,8 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180
 
   This metadata MUST be encoded in the same format as the `hash-source` (without
   the single quotes) in <a
-  href="http://www.w3.org/TR/CSP2/#source-list-syntax">section 4.2 of the Content
-  Security Policy Level 2 specification</a>.
+  href="http://www.w3.org/TR/CSP3/#framework-directive-source-list">section
+  2.3.1 of the Content Security Policy Level 3 specification</a>. [[!CSP3]]
 
   For example, given a script resource containing only the string `alert('Hello,
   world.');`, an author might choose <a>SHA-384</a> as a hash function.
@@ -451,24 +447,16 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180
   valid metadata as described by the following ABNF grammar:
 
   <pre dfn-type="grammar" link-type="grammar">
-      <dfn>integrity-metadata</dfn> = *<a>WSP</a> <a>hash-with-options</a> *(1*<a>WSP</a> <a>hash-with-options</a> ) *<a>WSP</a> / *<a>WSP</a>
-      <dfn>hash-with-options</dfn>  = <a>hash-expression</a> *("?" <a>option-expression</a>)
-      <dfn>option-expression</dfn>  = *<a>VCHAR</a>
-      <dfn>hash-algo</dfn>          = &lt;hash-algo production from [Content Security Policy Level 2, section 4.2]&gt;
-      <dfn>base64-value</dfn>       = &lt;base64-value production from [Content Security Policy Level 2, section 4.2]&gt;
+      <dfn>integrity-metadata</dfn> = *<a>WSP</a> <a>hash-expression</a> *(1*<a>WSP</a> <a>hash-expression</a> ) *<a>WSP</a> / *<a>WSP</a>
+      <dfn>hash-algo</dfn>          = &lt;hash-algo production from [Content Security Policy Level 3, section 2.3.1]&gt;
+      <dfn>base64-value</dfn>       = &lt;base64-value production from [Content Security Policy Level 3, section 2.3.1]&gt;
       <dfn>hash-expression</dfn>    = <a>hash-algo</a> "-" <a>base64-value</a>
   </pre>
-
-  `option-expression`s are associated on a per `hash-expression` basis and are
-  applied only to the `hash-expression` that immediately precedes it.
-
-  In order for user agents to remain fully forwards compatible with future
-  options, the user agent MUST ignore all unrecognized  `option-expression`s.
-
-  Note: Note that while the `option-expression` has been reserved in the syntax,
-  no options have been defined. It is likely that a future version of the spec
-  will define a more specific syntax for options, so it is defined here as broadly
-  as possible.
+  
+  Note: Since no `options` are not defined (see the
+  [[#integrity-metadata-description]]), the above ABNF syntax does not consider
+  them. If `options` are defined in a future version, the ABNF syntax should be
+  modified accordingly.
 
   ## Handling integrity violations ## {#handling-integrity-violations}