Grammer, spelling, and formatting fixes (#43)

100-CNAB.md

@@ -42,7 +42,7 @@ The current distributed computing landscape involves a combination of executable
 
 A bundle is comprised of a bundle definition and at least one _invocation image_. The invocation image's job is to install zero or more components into the host environment. Such components MAY include (but are not limited to) containers, functions, VMs, IaaS and PaaS layers, and service frameworks.
 
-The invocation image contains a standardized filesystem layout where metadata and installation data is stored in predictable places. A _run tool_ is a the executable entry point into a CNAB bundle. Parameterization and credentialing allow injection of configuration data into the main image. The invocation image is described in detail in [the invocation image definition](102-invocation-image.md).
+The invocation image contains a standardized filesystem layout where metadata and installation data is stored in predictable places. A _run tool_ is the executable entry point into a CNAB bundle. Parameterization and credentialing allow injection of configuration data into the invocation image. The invocation image is described in detail in [the invocation image definition](102-invocation-image.md).
 
 _Actions_ are sent to the `run` command via environment variables. Actions determine whether a bundle is to be installed, upgraded, downgraded, or uninstalled.
 
@@ -66,7 +66,7 @@ Bundles are stored in _bundle repositories_. A bundle repository is a network-ac
 - `bundle.cnab`: The signed JSON-encoded representation of a bundle definition.
 - Claim: A record of a particular installation of a bundle.
 - Image: Used generically, a container image (e.g. OCI images) or a VM image.
-- Invocation Image: The  image that contains the bootstrapping and installation logic for the bundle
+- Invocation Image: The image that contains the bootstrapping and installation logic for the bundle
 - Repository: A storage and retrieval service for CNAB objects.
 
 Also, when referencing tooling, we use the following terms:

101-bundle-json.md

@@ -62,7 +62,7 @@ The following is an example of a `bundle.json` for a bundled distributed as a _t
             "minValue": 10,
             "maxValue": 10240,
             "metadata": {
-               "description": "The port that the backend will listen on"
+               "description": "The port that the back-end will listen on"
             }
         }
     },
@@ -352,7 +352,7 @@ When resolving destinations, there are three ways a particular parameter value M
 The first parameter is `port`. This parameter has no destination field. Consequently, it's value will be injected into an environment variable whose prefix is `CNAB_P_`, with a capitalized version of the name (`PORT`) appended.
 
 ```
-PORT=8080
+CNAB_P_PORT=8080
 ```
 
 If the `destination` field is set, at least one of `env` or `path` MUST be specified. (Both MAY be provided).
@@ -447,11 +447,10 @@ Each action is accompanied by a description, which contains the following fields
 
 The `modifies` field MUST be set to `true` if any resource that is managed by the bundle is changed in any way. The `modifies` field assists CNAB implementations in tracking history of changes over time. An implementation of CNAB MAY use this information when describing history or managing releases.
 
-An invocation image _ought_ to handle all custom targets declared in the `actions` section. An invocation image SHOULD NOT handle actions that are not included by the default list (`install`, `upgrade, `uninstall`) and the custom actions section.
+An invocation image _ought_ to handle all custom targets declared in the `actions` section. An invocation image SHOULD NOT handle actions that are not included by the default list (`install`, `upgrade`, `uninstall`) and the custom actions section.
 
 The built-in actions (`install`, `upgrade`, `uninstall`) MUST NOT appear in the `actions` section, and an implementation MUST NOT allow custom actions named `install`, `upgrade`, or `uninstall`.
 
-Implementations that do not support custom actions MUST NOT emit errors (either runtime or validation) if a bundle defines custom actions. That is, even if an implementation cannot execute custom actions, it MUST NOT fail to operate on bundles that declare custom actions.
+Implementations that do not support custom actions MUST NOT emit errors (either runtime or validation) if a bundle defines custom actions. That is, even if an ismplementation cannot execute custom actions, it MUST NOT fail to operate on bundles that declare custom actions.
 
 Next section: [The invocation image definition](102-invocation-image.md)
-

103-bundle-runtime.md

@@ -68,7 +68,7 @@ elif [[ action == "uninstall" ]]; then
 fi
 ```
 
-This simple example executes Helm, installing the Wordpress chart with the default settings if `install` is sent, or deleting the installation if `uninstall` is sent.
+This simple example executes Helm, installing the WordPress chart with the default settings if `install` is sent, or deleting the installation if `uninstall` is sent.
 
 An implementation of a CNAB runtime MUST support sending the following actions to an invocation image:
 

105-signing.md

@@ -161,7 +161,7 @@ ANjudClHNUNQFojriAX8YAO4V2yGVg==
 -----END PGP SIGNATURE-----
 ```
 
-Note that because we have _clear signed_ the `bundle.json`, there is no longer any need to transmit the `bundle.json` separately from the signed bundle. In fact, due to encoding differences, it is _preferable to use the signed bundle in lieu of the unsigned bundle_. 
+Note that because we have _clear signed_ the `bundle.json`, there is no longer any need to transmit the `bundle.json` separately from the signed bundle. In fact, due to encoding differences, it is _preferable to use the signed bundle in lieu of the unsigned bundle_.
 
 ## Attestations
 
@@ -211,7 +211,7 @@ Cases MAY arise where a particular version (or versions) of a bundle should no l
 
 Reusing a release version to replace an insecure release with a secure one is _expressly prohibited_. For example, if release 2.3.1 of a bundle is deemed insecure, operators MUST NOT re-release a modified bundle as 2.3.1. The fixed version MUST modify a semantic component of the version number. For example, `2.3.2`, `2.4.0`, `3.0.0`, and even `2.3.2-alpha.1` are all acceptable increments. `2.3.1` and `2.3.1+1` are examples of forbidden version increments. Likewise, release `2.3.1` MUST NOT be renamed by semantic component. (e.g. 2.3.1-insecure is illegal, while 2.3.1+insecure is legal). For clarification on this policy, see the [SemVer 2 specification](https://semver.org).
 
-Instead, the prefered pattern is to retain the insecure release at its given release number, but issue a _retraction_.
+Instead, the preferred pattern is to retain the insecure release at its given release number, but issue a _retraction_.
 
 A *retraction* is a cryptographically signed indicator that a bundle MAY be installed.
 
@@ -252,7 +252,7 @@ A retraction is a clear signed JSON array.
 
 The `signature` field is OPTIONAL, but provides a content-specific test on the content retracted. It is only applicable to cases where a specific version is being retracted.
 
-The `version` field is OPTIONAL. If omitted, the entire Bundle is considerered retracted. When `version` is omitted, `signature` MUST be omitted.
+The `version` field is OPTIONAL. If omitted, the entire Bundle is considered retracted. When `version` is omitted, `signature` MUST be omitted.
 
 To specify a range of versions, a _SemVer range_ MAY be provided in the `version` field. In this case, a `signature` MUST be omitted.
 
@@ -272,7 +272,7 @@ Hash: SHA512
     },
     {
         "bundle": "helloseattle",
-        "reason": "the helloseattle tool has been removed do to licensing restrictions"
+        "reason": "the helloseattle tool has been removed due to licensing restrictions"
     },
     {
         "bundle": "fireflies",

200-repositories.md

@@ -208,7 +208,7 @@ The request MUST contain exactly one query parameter, `service=$servicename`, wh
 
 Service names are defined as a particular action (e.g. "upload-bundle") that both the client and the server understand for a particular operation, such as uploading bundles, logging in, fetching bundles, etc.
 
-Because the communication protocol between the client and the server is left up entirely to the implementaton of the requested service name, no request type (such as GET/POST/PUT/PATCH) is REQUIRED, but for demonstration purposes we are demonstrating the protocol using a GET request.
+Because the communication protocol between the client and the server is left up entirely to the implementation of the requested service name, no request type (such as GET/POST/PUT/PATCH) is REQUIRED, but for demonstration purposes we are demonstrating the protocol using a GET request.
 
 ```bash
 GET $REPO_URL?service=upload-bundle HTTP/1.1
@@ -314,7 +314,7 @@ In early versions of reference implementations of the CNAB spec, we experimented
 
 CNAB clients should be able to handle the entire repository lifecycle, from logging in, searching, publishing, and fetching bundles.
 
-As a reference implentation to the CNAB spec, Duffle implements the following commands to handle a CNAB repository's lifecycle:
+As a reference implementation to the CNAB spec, Duffle implements the following commands to handle a CNAB repository's lifecycle:
 
 - `duffle login` logs in to a bundle repository
 - `duffle logout` logs out from a bundle repository

802-credential-sets.md

@@ -62,9 +62,9 @@ Similar tooling could choose to load the values by name from a database, vault,
 Credentials must be injected into the runtime of the invocation image. The following strategies are known to work:
 
 - Environment Variables:
-    - Injected via environment variable services (Docker and Kubernetes)
-    - Loaded into VMs via cloud-init
+  - Injected via environment variable services (Docker and Kubernetes)
+  - Loaded into VMs via cloud-init
 - Paths:
-    - Mounted as volumes (or wrappers, such as Kubernetes secrets)
-    - Injected at runtime into the top layer of the container
-    - Loaded into VMs via cloud-init
+  - Mounted as volumes (or wrappers, such as Kubernetes secrets)
+  - Injected at runtime into the top layer of the container
+  - Loaded into VMs via cloud-init

901-process.md

@@ -17,7 +17,7 @@ The specification will proceed through the following phases:
 - *Working Draft (WD)*: During this phase, the specification is open for review. During this phase, major (breaking) changes may be made.
 - *Candidate Recommendation (CR)*: This phase indicates that a final review is immanent. During this phase, minor (non-breaking) changes may be made, and major changes will be considered if they present an immanent problem with the specification.
 - *Recommendation (REC)*: This phase indicates that the specification is stable, and the present version is no longer open for changes to the conformance of the specification
-    - W3C [class 1 and 2 changes](https://www.w3.org/2017/Process-20170301/#correction-classes) are allowed on a recommendation.
-    - W3C class 3 and 4 changes can be addressed in a _minor version update_.
+  - W3C [class 1 and 2 changes](https://www.w3.org/2017/Process-20170301/#correction-classes) are allowed on a recommendation.
+  - W3C class 3 and 4 changes can be addressed in a _minor version update_.
 
 And [errata section](https://www.w3.org/2017/Process-20170301/#rec-modify) may be added to a specification as an appendix, as a location for tracking clarifications and changes.