Fix typos (#387)

Author: martinbonnin

rfcs/GraphQLOverSSE.md

@@ -59,11 +59,11 @@ interface CompleteMessage {
 
 Having aforementioned limitations in mind, a "single connection mode" is proposed. In this mode, a single established SSE connection transmits **all** results from the server while separate HTTP requests dictate the behaviour.
 
-Additionally, due to various limitations with the browser's native [`EventSource` interface](https://developer.mozilla.org/en-US/docs/Web/API/EventSource), like the lack of supplying custom headers or vague connection error information, a "reservation" tactic is RECOMMENDED. This means that the client requests an SSE connection reservation from the server through a regular HTTP request which is later fulfiled with the actual SSE connection matching the reservation requirements.
+Additionally, due to various limitations with the browser's native [`EventSource` interface](https://developer.mozilla.org/en-US/docs/Web/API/EventSource), like the lack of supplying custom headers or vague connection error information, a "reservation" tactic is RECOMMENDED. This means that the client requests an SSE connection reservation from the server through a regular HTTP request which is later fulfilled with the actual SSE connection matching the reservation requirements.
 
 ### Making reservations
 
-The client requests a reservation for an incoming SSE connection through a `PUT` HTTP request. Since this is a regular HTTP request, it may transmit authentication details however the implementor sees fit.
+The client requests a reservation for an incoming SSE connection through a `PUT` HTTP request. Since this is a regular HTTP request, it may transmit authentication details however the implementer sees fit.
 
 The server accepts the reservation request by responding with `201` (Created) and a reservation token in the body of the response. This token is then presented alongside the incoming SSE connection as an entrance ticket. If using the [`EventSource` interface](https://developer.mozilla.org/en-US/docs/Web/API/EventSource), the token may be encoded in the URL's search parameters.
 
@@ -78,7 +78,7 @@ For security reasons, **only one** SSE connection can fulfil a reservation at a
 
 While having a single SSE connection (or reservation), separate HTTP requests solicit GraphQL operations conforming to the [GraphQL over HTTP spec](https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md) with **only one difference**: successful responses (execution results) get accepted with a `202` (Accepted) and are then streamed through the single SSE connection. Validation issues and other request problems are handled as documented in the [GraphQL over HTTP spec](https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md).
 
-Since the client holds the task of publishing the SSE messages to the relevant listeners through a single connection, an operation ID identifying the messages destinations is necessary. The unique operation ID SHOULD be sent through the `extensions` parameter of the GraphQL reqeust inside the `operationId` field. This operation ID accompanies the SSE messages for destination discovery (more details below).
+Since the client holds the task of publishing the SSE messages to the relevant listeners through a single connection, an operation ID identifying the messages destinations is necessary. The unique operation ID SHOULD be sent through the `extensions` parameter of the GraphQL request inside the `operationId` field. This operation ID accompanies the SSE messages for destination discovery (more details below).
 
 The HTTP request MUST contain the matching reservation token.
 

rfcs/GraphQLOverWebSocket.md

@@ -104,7 +104,7 @@ Requests an operation specified in the message `payload`. This message provides
 
 If there is already an active subscriber for an operation matching the provided ID, regardless of the operation type, the server **must** close the socket immediately with the event `4409: Subscriber for <unique-operation-id> already exists`.
 
-The server needs only keep track of IDs for as long as the subscription is active. Once a client completes an operation, it is free to re-use that ID.
+The server needs only keep track of IDs for as long as the subscription is active. Once a client completes an operation, it is free to reuse that ID.
 
 ```typescript
 interface SubscribeMessage {
@@ -176,7 +176,7 @@ Direction: **bidirectional**
 
 Receiving a message of a type or format which is not specified in this document will result in an **immediate** socket closure with the event `4400: <error-message>`. The `<error-message>` can be vaguely descriptive on why the received message is invalid.
 
-Receiving a message (other than `Subscribe`) with an ID that belongs to an operation that has been previously completed does not constitute an error. It is permissable to simply ignore all _unknown_ IDs without closing the connection.
+Receiving a message (other than `Subscribe`) with an ID that belongs to an operation that has been previously completed does not constitute an error. It is permissible to simply ignore all _unknown_ IDs without closing the connection.
 
 ## Examples
 

rfcs/IncrementalDelivery.md

@@ -18,7 +18,7 @@ Compliant servers must follow the HTTP/2 specification and not set the `Transfer
 
 ## `Content-Type: multipart/mixed`
 
-The HTTP response for an incrementally delivered response should conform to the [specification of multipart content defined by the W3 in rfc1341](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html). The HTTP response must contain the `Content-Type` response header with a specified boundary, for example `Content-Type: multipart/mixed; boundary="-"`. A simple boundary of `-` can be used as there is no possiblity of conflict with JSON data. However, any arbitrary boundary may be used.
+The HTTP response for an incrementally delivered response should conform to the [specification of multipart content defined by the W3 in rfc1341](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html). The HTTP response must contain the `Content-Type` response header with a specified boundary, for example `Content-Type: multipart/mixed; boundary="-"`. A simple boundary of `-` can be used as there is no possibility of conflict with JSON data. However, any arbitrary boundary may be used.
 
 An example response body will look like:
 

working-group/agendas/2020/2020-01-28.md

@@ -71,4 +71,4 @@ _Planned for next meeting_
 _Later_
 
 - [ ] ???? - Draft a standard sample schema - Dependent on list of things to test
-- [ ] Create sample servers to help test compliancy (i.e. graphql-express, graphql-api-koa, etc)
+- [ ] Create sample servers to help test compliance (i.e. graphql-express, graphql-api-koa, etc)