Formatting

Author: bershanskiy

Diff for: proposals/manifest_trial_tokens.md

@@ -29,7 +29,7 @@ into all contexts with the extension's origin.
 
 #### Use Cases
 
-Greater availability and beter ergonomics of Origin and Deprecation tokens.
+Greater availability and better ergonomics of Origin and Deprecation tokens.
 
 ##### Participation in Origin and Deprecation Trials for Open Web APIs
 
@@ -41,15 +41,15 @@ legacy behaviors and deprecated APIs.
 ##### Creation of Origin and Deprecation Trials for WebExtension APIs
 
 As of writing, WebExtension system does not have a convenient way of shipping
-changes to WebExtension APIs. In leu of Origin Trials framework browsers resort
+changes to WebExtension APIs. In lieu of Origin Trials framework browsers resort
 to workarounds (or their combination):
- - make the change backwards-compatiable, if possible, with perpetually
+ - make the change backwards-compatible, if possible, with perpetually
    deprecated legacy behavior. This keeps around deprecated code paths and
-   behaviors indefinitelly. This could be resolved via deprecation trials.
- - launch an enirely different API under a new name, keeping around the old
-   code paths and behaviors indefinitelly.
+   behaviors indefinitely. This could be resolved via deprecation trials.
+ - launch an entirely different API under a new name, keeping around the old
+   code paths and behaviors indefinitely.
  - launch a change to pre-release Canary/Nightly and Beta channels and
-   and ask for developer feedback prior to launch to Stable. Some issues slip
+   ask for developer feedback prior to launch to Stable. Some issues slip
    through this testing and get fossilized in the final API. This could be
    resolved via origin trails.
  - limit the change via allow- and block-lists specified at in browser source
@@ -93,33 +93,33 @@ Upon manifest parsing, browser should parse `trial_tokens` like so:
    warnings
  - browsers can limit the total number of parsed and/or accepted tokens
  - browsers can limit the length of each token
- - browsers can limit the the total length of all parsed and/or accepted tokens
+ - browsers can limit the total length of all parsed and/or accepted tokens
  - browsers can validate token structure, content, and signature at parse time;
-   in particular, tokens should not contain conrol characters like new lines
-   and charaxter returns which could affect HTTP header serealization and
+   in particular, tokens should not contain control characters like new lines
+   and charaxter returns which could affect HTTP header serialization and
    parsing
 
 #### Manifest parsing algorithm
  1. if `trial_tokens` is not present, return
  2. if `trial_tokens` is not an array or if `trial_tokens` is an empty array,
     (optionally) log a benign warning and return
  3. for every element `token` of `trial_tokens`:
-   3.1. (optionally) if the maximum number of accepted tokens is reached,
-        skip all other tokens
-   3.2. if `token` is not a string, skip it and (optionally) log a benign
-        warning
-   3.2. if `token` is an empty string, skip it and (optionally) log a benign
-        warning
-   3.3. (optionally) if `token` is too long to be parsed, skip it and
-        (optionally) log a benign warning
-   3.4. if token has been encountered before, skip it and (optionally) log
-        a benign warning
-   3.5. (optionally) attempt to parse the token and validate it. If validation
-        fails, skip the token and (optionally) log a benign warning.
-        Note: browsers may disregard token expiration errors, if they are not
-        sure about the corrctness of system timestamp at the time of token
-        validation
-   3.6. append token to the collection of accepted tokens
+    1. (optionally) if the maximum number of accepted tokens is reached,
+       skip all other tokens
+    2. if `token` is not a string, skip it and (optionally) log a benign
+       warning
+    3. if `token` is an empty string, skip it and (optionally) log a benign
+       warning
+    4. (optionally) if `token` is too long to be parsed, skip it and
+       (optionally) log a benign warning
+    5. if token has been encountered before, skip it and (optionally) log
+       a benign warning
+    6. (optionally) attempt to parse the token and validate it. If validation
+       fails, skip the token and (optionally) log a benign warning.
+       Note: browsers may disregard token expiration errors if they are not
+       sure about the correctness of system timestamp at the time of token
+       validation
+    7. append token to the collection of accepted tokens
  4. if at least one token is accepted in step 3, save the token collection in
     parsed manifest under `trial_tokens` key
 
@@ -153,10 +153,10 @@ Trial tokens system already incorporate some degree of abuse mitigations:
 
 This new manifest key contains values which will be inserted into headers of
 local HTTP-like responses. Browsers must ensure that the provided tokens can
-not escape header serealization. Browsers also must ensure that tokens do not
+not escape header serialization. Browsers also must ensure that tokens do not
 cause headers to exceed implementation-specific limits so that response is
-processed in  different way (e.g., adding a large number of tokens must not
-cuase removal of security headers like CSP).
+processed in  different way (e.g., a large number of long tokens must not
+cuase removal of other headers or response content).
 
 ## Alternatives
 
@@ -167,7 +167,7 @@ cuase removal of security headers like CSP).
 Document contexts can activate tokens by
 [embedding them in DOM](<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">)
 `<meta>` tag, both statically and dynamically. Extension service workers can
-spawn documents and with embedded tokens and proxy calls to trial features via
+spawn documents and embedded tokens and proxy calls to trial features via
 the said document.
 
 ## Implementation Notes