Fix spelling and grammar issues

Signed-off-by: Philipp Emanuel Weidmann <[email protected]>

Author: p-e-w

specification/appendices/identifier_grammar.rst

@@ -152,7 +152,7 @@ The complete grammar for a legal user ID is::
   set. User IDs are primarily intended for use as an identifier at the protocol
   level, and their use as a human-readable handle is of secondary
   benefit. Furthermore, they are useful as a last-resort differentiator between
-  users with similar display names. Allowing the full unicode character set
+  users with similar display names. Allowing the full Unicode character set
   would make very difficult for a human to distinguish two similar user IDs. The
   limited character set used has the advantage that even a user unfamiliar with
   the Latin alphabet should be able to distinguish similar user IDs manually, if
@@ -190,7 +190,7 @@ history includes events with a ``sender`` which does not conform. In order to
 handle these rooms successfully, clients and servers MUST accept user IDs with
 localparts from the expanded character set::
 
-  extended_user_id_char = %x21-39 / %x3B-7E  ; all ascii printing chars except :
+  extended_user_id_char = %x21-39 / %x3B-7E  ; all ASCII printing chars except :
 
 Mapping from other character sets
 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
@@ -251,8 +251,8 @@ risk of clashes of identifiers between different homeservers. There is no
 implication that the room or event in question is still available at the
 corresponding homeserver.
 
-Event IDs and Room IDs are case-sensitive. They are not meant to be human
-readable. They are intended to be treated as fully opaque strings by clients.
+Event IDs and Room IDs are case-sensitive. They are not meant to be human-readable.
+They are intended to be treated as fully opaque strings by clients.
 
 .. TODO-spec
   What is the grammar for the opaque part? https://matrix.org/jira/browse/SPEC-389
@@ -326,7 +326,7 @@ parameter is only used in the case of permalinks where an event ID is referenced
 The matrix.to URI, when referenced, must always start with ``https://matrix.to/#/``
 followed by the identifier.
 
-The ``<additional arguments>`` and the preceeding question mark are optional and
+The ``<additional arguments>`` and the preceding question mark are optional and
 only apply in certain circumstances, documented below.
 
 Clients should not rely on matrix.to URIs falling back to a web server if accessed
@@ -379,7 +379,7 @@ are picked is left as an implementation detail, however the current recommendati
 to pick 3 unique servers based on the following criteria:
 
 * The first server should be the server of the highest power level user in the room,
-  provided they are at least power level 50. If no user meets this criteria, pick the
+  provided they are at least power level 50. If no user meets these criteria, pick the
   most popular server in the room (most joined users). The rationale for not picking
   users with power levels under 50 is that they are unlikely to be around into the
   distant future while higher ranking users (and therefore servers) are less likely

specification/appendices/signing_json.rst

@@ -29,7 +29,7 @@ Canonical JSON
 ~~~~~~~~~~~~~~
 
 We define the canonical JSON encoding for a value to be the shortest UTF-8 JSON
-encoding with dictionary keys lexicographically sorted by unicode codepoint.
+encoding with dictionary keys lexicographically sorted by Unicode codepoint.
 Numbers in the JSON must be integers in the range ``[-(2**53)+1, (2**53)-1]``.
 
 We pick UTF-8 as the encoding as it should be available to all platforms and
@@ -63,7 +63,7 @@ using this representation.
          separators=(',',':'),
          # Sort the keys of dictionaries.
          sort_keys=True,
-         # Encode the resulting unicode as UTF-8 bytes.
+         # Encode the resulting Unicode as UTF-8 bytes.
      ).encode("UTF-8")
 
 Grammar

specification/appendices/threat_model.rst

@@ -28,7 +28,7 @@ victim in order to:
 Threat: Resource Exhaustion
 +++++++++++++++++++++++++++
 
-An attacker could cause the victims server to exhaust a particular resource
+An attacker could cause the victim's server to exhaust a particular resource
 (e.g. open TCP connections, CPU, memory, disk storage)
 
 Threat: Unrecoverable Consistency Violations

specification/application_service_api.rst

@@ -194,7 +194,7 @@ Authorization
 Homeservers MUST include a query parameter named ``access_token`` containing the
 ``hs_token`` from the application service's registration when making requests to
 the application service. Application services MUST verify the provided ``access_token``
-matches their known ``hs_token``, failing the request with a ``M_FORBIDDEN`` error
+matches their known ``hs_token``, failing the request with an ``M_FORBIDDEN`` error
 if it does not match.
 
 Legacy routes
@@ -206,8 +206,8 @@ service specification now defines a version on all endpoints to be more compatib
 with the rest of the Matrix specification and the future.
 
 Homeservers should attempt to use the specified endpoints first when communicating
-with application services. However, if the application service receives an http status
-code that does not indicate success (ie: 404, 500, 501, etc) then the homeserver
+with application services. However, if the application service receives an HTTP status
+code that does not indicate success (i.e.: 404, 500, 501, etc) then the homeserver
 should fall back to the older endpoints for the application service.
 
 The older endpoints have the exact same request body and response format, they

specification/client_server_api.rst

@@ -186,7 +186,7 @@ Other error codes the client might encounter are:
   permits, for example, email addresses from a particular domain.
 
 :``M_SERVER_NOT_TRUSTED``:
-  The client's request used a third party server, eg. identity server, that this server does not trust.
+  The client's request used a third party server, e.g. identity server, that this server does not trust.
 
 :``M_UNSUPPORTED_ROOM_VERSION``:
   The client's request to create a room used a room version that the server does not support.
@@ -228,8 +228,8 @@ Other error codes the client might encounter are:
   may reach a resource limit if it starts using too much memory or disk space. The
   error MUST have an ``admin_contact`` field to provide the user receiving the error
   a place to reach out to. Typically, this error will appear on routes which attempt
-  to modify state (eg: sending messages, account data, etc) and not routes which only
-  read state (eg: ``/sync``, get account data, etc).
+  to modify state (e.g.: sending messages, account data, etc) and not routes which only
+  read state (e.g.: ``/sync``, get account data, etc).
 
 :``M_CANNOT_LEAVE_SERVER_NOTICE_ROOM``:
   The user is unable to reject an invite to join the server notices room. See the
@@ -266,8 +266,8 @@ to pre-flight requests and supply Cross-Origin Resource Sharing (CORS) headers o
 all requests.
 
 Servers MUST expect that clients will approach them with ``OPTIONS`` requests,
-allowing clients to discover the CORS headers. All endpoints in this specification s
-upport the ``OPTIONS`` method, however the server MUST NOT perform any logic defined
+allowing clients to discover the CORS headers. All endpoints in this specification
+support the ``OPTIONS`` method, however the server MUST NOT perform any logic defined
 for the endpoints when approached with an ``OPTIONS`` request.
 
 When a client approaches the server with a request, the server should respond with
@@ -438,7 +438,7 @@ homeserver may provide many different ways of authenticating, such as
 user/password auth, login via a single-sign-on server (SSO), etc. This
 specification does not define how homeservers should authorise their users but
 instead defines the standard interface which implementations should follow so
-that ANY client can login to ANY homeserver.
+that ANY client can log in to ANY homeserver.
 
 The process takes the form of one or more 'stages'. At each stage the client
 submits a set of data for a given authentication type and awaits a response
@@ -707,7 +707,7 @@ For example, to authenticate using the user's Matrix ID, clients would submit:
   }
 
 Alternatively reply using a 3PID bound to the user's account on the homeserver
-using the |/account/3pid|_ API rather then giving the ``user`` explicitly as
+using the |/account/3pid|_ API rather than giving the ``user`` explicitly as
 follows:
 
 .. code:: json
@@ -827,7 +827,7 @@ Dummy Auth
   Dummy authentication always succeeds and requires no extra parameters. Its
   purpose is to allow servers to not require any form of User-Interactive
   Authentication to perform a request. It can also be used to differentiate
-  flows where otherwise one flow would be a subset of another flow. eg. if
+  flows where otherwise one flow would be a subset of another flow. e.g. if
   a server offers flows ``m.login.recaptcha`` and ``m.login.recaptcha,
   m.login.email.identity`` and the client completes the recaptcha stage first,
   the auth would succeed with the former flow, even if the client was intending
@@ -878,7 +878,7 @@ to be defined in an embedded browser, or to use the HTML5 `cross-document
 messaging <https://www.w3.org/TR/webmessaging/#web-messaging>`_ API, to receive
 a notification that the authentication stage has been completed.
 
-Once a client receives the notificaton that the authentication stage has been
+Once a client receives the notification that the authentication stage has been
 completed, it should resubmit the request with an auth dict with just the
 session ID:
 
@@ -891,19 +891,19 @@ session ID:
 
 Example
 <<<<<<<
-A client webapp might use the following javascript to open a popup window which will
+A client webapp might use the following JavaScript to open a popup window which will
 handle unknown login types:
 
 .. code:: javascript
 
   /**
    * Arguments:
-   *     homeserverUrl: the base url of the homeserver (eg "https://matrix.org")
+   *     homeserverUrl: the base url of the homeserver (e.g. "https://matrix.org")
    *
-   *     apiEndpoint: the API endpoint being used (eg
+   *     apiEndpoint: the API endpoint being used (e.g.
    *        "/_matrix/client/%CLIENT_MAJOR_VERSION%/account/password")
    *
-   *     loginType: the loginType being attempted (eg "m.login.recaptcha")
+   *     loginType: the loginType being attempted (e.g. "m.login.recaptcha")
    *
    *     sessionID: the session ID given by the homeserver in earlier requests
    *
@@ -930,7 +930,7 @@ handle unknown login types:
           };
 
           request({
-              method:'POST', url:apiEndpint, json:requestBody,
+              method:'POST', url:apiEndpoint, json:requestBody,
           }, onComplete);
       };
 
@@ -1044,7 +1044,7 @@ request as follows:
   }
 
 Alternatively, a client can use a 3PID bound to the user's account on the
-homeserver using the |/account/3pid|_ API rather then giving the ``user``
+homeserver using the |/account/3pid|_ API rather than giving the ``user``
 explicitly, as follows:
 
 .. code:: json
@@ -1130,7 +1130,7 @@ can be proxied (bound) to the identity server in many cases.
   This section deals with two terms: "add" and "bind". Where "add" (or "remove")
   is used, it is speaking about an identifier that was not bound to an identity
   server. As a result, "bind" (or "unbind") references an identifier that is found
-  in an identity server. Note that an identifer can be added and bound at the same
+  in an identity server. Note that an identifier can be added and bound at the same
   time, depending on context.
 
 {{administrative_contact_cs_http_api}}
@@ -1745,7 +1745,7 @@ same way a server does.
     except those protected by the redaction algorithm. For example,
     a redacted ``join`` event will still result in the user being considered joined.
     Similarly, a redacted topic does not necessarily cause the topic to revert to
-    what is was prior to the event - it causes the topic to be removed from the room.
+    what it was prior to the event - it causes the topic to be removed from the room.
 
 
 Events
@@ -1977,9 +1977,9 @@ many places of a client's display, changes to these fields cause an automatic
 propagation event to occur, informing likely-interested parties of the new
 values. This change is conveyed using two separate mechanisms:
 
-- a ``m.room.member`` event (with a ``join`` membership) is sent to every room
+- an ``m.room.member`` event (with a ``join`` membership) is sent to every room
   the user is a member of, to update the ``displayname`` and ``avatar_url``.
-- a ``m.presence`` presence status update is sent, again containing the new
+- an ``m.presence`` presence status update is sent, again containing the new
   values of the ``displayname`` and ``avatar_url`` keys, in addition to the
   required ``presence`` key containing the current presence state of the user.
 

specification/identity_service_api.rst

@@ -225,7 +225,7 @@ Terms of service
 
 Identity Servers are encouraged to have terms of service (or similar policies) to
 ensure that users have agreed to their data being processed by the server. To facilitate
-this, an identity server can respond to almost any authenticated API endpoint with a
+this, an identity server can respond to almost any authenticated API endpoint with an
 HTTP 403 and the error code ``M_TERMS_NOT_SIGNED``. The error code is used to indicate
 that the user must accept new terms of service before being able to continue.
 
@@ -421,7 +421,7 @@ i.e. I can claim that any email address I own is associated with
 Sessions are time-limited; a session is considered to have been modified when
 it was created, and then when a validation is performed within it. A session can
 only be checked for validation, and validation can only be performed within a
-session, within a 24 hour period since its most recent modification. Any
+session, within a 24-hour period since its most recent modification. Any
 attempts to perform these actions after the expiry will be rejected, and a new
 session should be created and used instead.
 

specification/index.rst

@@ -431,7 +431,7 @@ Profiles
 ~~~~~~~~
 
 Users may publish arbitrary key/value data associated with their account - such
-as a human readable display name, a profile photo URL, contact information
+as a human-readable display name, a profile photo URL, contact information
 (email address, phone numbers, website URLs etc).
 
 .. TODO