Replace authorization with authorisation throughout the spec

content/application-service-api.md

@@ -100,7 +100,7 @@ this.
 
 ### Homeserver -> Application Service API
 
-#### Authorization
+#### Authorisation
 
 {{% changed-in v="1.4" %}}
 

content/changelog/v1.14.md

@@ -63,7 +63,7 @@ No significant changes.
 
 **Spec Clarifications**
 
-- For room versions 6 and 7, clarify in the authorization rules that `m.federate` must be checked and that events with rejected auth events must be rejected, for parity with all the other room versions. ([#2065](https://github.com/matrix-org/matrix-spec/issues/2065))
+- For room versions 6 and 7, clarify in the authorisation rules that `m.federate` must be checked and that events with rejected auth events must be rejected, for parity with all the other room versions. ([#2065](https://github.com/matrix-org/matrix-spec/issues/2065))
 - Fix various typos throughout the specification. ([#2066](https://github.com/matrix-org/matrix-spec/issues/2066))
 - Refactor PDU definitions to reduce duplication. ([#2070](https://github.com/matrix-org/matrix-spec/issues/2070))
 - Clarify the maximum `depth` value for room versions 6, 7, 8, 9, 10, and 11. ([#2114](https://github.com/matrix-org/matrix-spec/issues/2114))

content/changelog/v1.3.md

@@ -108,12 +108,12 @@ No significant changes.
 
 
 - Improve readability and understanding of the state resolution algorithms. ([#1037](https://github.com/matrix-org/matrix-spec/issues/1037), [#1042](https://github.com/matrix-org/matrix-spec/issues/1042), [#1043](https://github.com/matrix-org/matrix-spec/issues/1043), [#1120](https://github.com/matrix-org/matrix-spec/issues/1120))
-- Improve readability of the authorization rules. ([#1050](https://github.com/matrix-org/matrix-spec/issues/1050))
+- Improve readability of the authorisation rules. ([#1050](https://github.com/matrix-org/matrix-spec/issues/1050))
 - For room versions 8, 9, and 10: clarify which homeserver is required to sign the join event. ([#1093](https://github.com/matrix-org/matrix-spec/issues/1093))
 - Clarify that room versions 1 through 9 accept stringy power levels, as noted by [MSC3667](https://github.com/matrix-org/matrix-spec-proposals/pull/3667). ([#1099](https://github.com/matrix-org/matrix-spec/issues/1099))
-- For all room versions: Add `m.federate` to the authorization rules, as originally intended. ([#1103](https://github.com/matrix-org/matrix-spec/issues/1103))
+- For all room versions: Add `m.federate` to the authorisation rules, as originally intended. ([#1103](https://github.com/matrix-org/matrix-spec/issues/1103))
 - For room versions 2 through 10: More explicitly define the mainline of a power event and the mainline ordering of other events. ([#1107](https://github.com/matrix-org/matrix-spec/issues/1107))
-- For room versions 7, 8, 9, and 10: fix join membership authorization rules when `join_rule` is `knock`. ([#3737](https://github.com/matrix-org/matrix-spec-proposals/issues/3737))
+- For room versions 7, 8, 9, and 10: fix join membership authorisation rules when `join_rule` is `knock`. ([#3737](https://github.com/matrix-org/matrix-spec-proposals/issues/3737))
 
 
 ## Appendices

content/changelog/v1.4.md

@@ -73,7 +73,7 @@ date: 2022-09-29
 <strong>Breaking Changes</strong>
 
 
-- Replace homeserver authorization approach with an `Authorization` header instead of `access_token` when talking to the application service, as per [MSC2832](https://github.com/matrix-org/matrix-spec-proposals/pull/2832). ([#1200](https://github.com/matrix-org/matrix-spec/issues/1200))
+- Replace homeserver authorisation approach with an `Authorization` header instead of `access_token` when talking to the application service, as per [MSC2832](https://github.com/matrix-org/matrix-spec-proposals/pull/2832). ([#1200](https://github.com/matrix-org/matrix-spec/issues/1200))
 
 
 <strong>Spec Clarifications</strong>

content/rooms/_index.md

@@ -68,7 +68,7 @@ The available room versions are:
 -   [Version 5](/rooms/v5) - **Stable**. Introduces enforcement of
     signing key validity periods.
 -   [Version 6](/rooms/v6) - **Stable**. Alters several
-    authorization rules for events.
+    authorisation rules for events.
 -   [Version 7](/rooms/v7) - **Stable**. Introduces knocking.
 -   [Version 8](/rooms/v8) - **Stable**. Adds a join rule to allow members
     of another room to join without invite.
@@ -85,7 +85,7 @@ The available room versions are:
 
 Room versions are used to change properties of rooms that may not be
 compatible with other servers. For example, changing the rules for event
-authorization would cause older servers to potentially end up in a
+authorisation would cause older servers to potentially end up in a
 split-brain situation due to not understanding the new rules.
 
 A room version is defined as a string of characters which MUST NOT

content/rooms/fragments/v1-auth-rules.md

@@ -1,5 +1,5 @@
 
-The types of state events that affect authorization are:
+The types of state events that affect authorisation are:
 
 -   [`m.room.create`](/client-server-api#mroomcreate)
 -   [`m.room.member`](/client-server-api#mroommember)

content/rooms/fragments/v2-state-res.md

@@ -123,11 +123,11 @@ events: for events *x* and *y*, *x* < *y* if
 The *iterative auth checks algorithm* takes as input an initial room
 state and a sorted list of state events, and constructs a new room state
 by iterating through the event list and applying the state event to the
-room state if the state event is allowed by the [authorization
-rules](/server-server-api#authorization-rules).
-If the state event is not allowed by the authorization rules, then the
+room state if the state event is allowed by the [authorisation
+rules](/server-server-api#authorisation-rules).
+If the state event is not allowed by the authorisation rules, then the
 event is ignored. If a `(event_type, state_key)` key that is required
-for checking the authorization rules is not present in the state, then
+for checking the authorisation rules is not present in the state, then
 the appropriate state event from the event's `auth_events` is used if
 the auth event is not rejected.
 

content/rooms/fragments/v3-auth-rules.md

@@ -7,7 +7,7 @@ in the same respect, so does not need a signature from that server.
 The event must still be signed by the server denoted by the `sender` property,
 however.
 
-The types of state events that affect authorization are:
+The types of state events that affect authorisation are:
 
 -   [`m.room.create`](/client-server-api#mroomcreate)
 -   [`m.room.member`](/client-server-api#mroommember)

content/rooms/fragments/v3-handling-redactions.md

@@ -1,11 +1,11 @@
 ---
 ---
 {{% added-in v=3 %}} In room versions 1 and 2, redactions were
-explicitly part of the [authorization rules](/rooms/v1/#authorization-rules)
+explicitly part of the [authorisation rules](/rooms/v1/#authorisation-rules)
 under Rule 11. As of room version 3, these conditions no longer exist as
-represented by [this version's authorization rules](#authorization-rules).
+represented by [this version's authorisation rules](#authorisation-rules).
 
-While redactions are always accepted by the authorization rules for
+While redactions are always accepted by the authorisation rules for
 events, they should not be sent to clients until both the redaction
 event and the event the redaction affects have been received, and can
 be validated. If both events are valid and have been seen by the server,

content/rooms/fragments/v8-auth-rules.md

@@ -1,7 +1,7 @@
 
 Events must be signed by the server denoted by the `sender` property.
 
-The types of state events that affect authorization are:
+The types of state events that affect authorisation are:
 
 -   [`m.room.create`](/client-server-api#mroomcreate)
 -   [`m.room.member`](/client-server-api#mroommember)

content/rooms/v1.md

@@ -61,7 +61,7 @@ Events in version 1 rooms have the following structure:
 
 {{% rver-fragment name="v1-floaty-power-levels" %}}
 
-### Authorization rules
+### Authorisation rules
 
 {{% rver-fragment name="v1-auth-rules" %}}
 
@@ -106,7 +106,7 @@ results of the resolution so far.
         `sha1(event_id)`.
     -   Add the first event in the list to *R*.
     -   For each subsequent event in the list, check that the event
-        would be allowed by the authorization rules for a room in state
+        would be allowed by the authorisation rules for a room in state
         *R*. If the event would be allowed, then update *R* with the
         event and continue with the next event in the list. If it would
         not be allowed, stop and continue below with `m.room.join_rules`
@@ -115,7 +115,7 @@ results of the resolution so far.
     events.
 -   Repeat the above process for conflicts between `m.room.member`
     events.
--   No other events affect the authorization rules, so for all other
+-   No other events affect the authorisation rules, so for all other
     conflicts, just pick the event with the highest depth and lowest
     `sha1(event_id)` that passes authentication in *R* and add it to
     *R*.

content/rooms/v10.md

@@ -71,13 +71,13 @@ power levels could be represented as strings for backwards compatibility.
 
 This backwards compatibility is removed in this room version - power levels MUST NOT
 be represented as strings within this room version. Power levels which are not
-correctly structured are rejected under the authorization rules below.
+correctly structured are rejected under the authorisation rules below.
 
-### Authorization rules
+### Authorisation rules
 
 Events must be signed by the server denoted by the `sender` property.
 
-The types of state events that affect authorization are:
+The types of state events that affect authorisation are:
 
 -   [`m.room.create`](/client-server-api#mroomcreate)
 -   [`m.room.member`](/client-server-api#mroommember)

content/rooms/v11.md

@@ -80,11 +80,11 @@ For improved compatibility with newer clients, servers should add a `redacts` pr
 to the `content` of `m.room.redaction` events in *older* room versions when serving
 such events over the Client-Server API.
 
-### Authorization rules
+### Authorisation rules
 
 Events must be signed by the server denoted by the `sender` property.
 
-The types of state events that affect authorization are:
+The types of state events that affect authorisation are:
 
 -   [`m.room.create`](/client-server-api#mroomcreate)
 -   [`m.room.member`](/client-server-api#mroommember)

content/rooms/v12.md

@@ -43,11 +43,11 @@ Room version 12 is based upon room version 11 with the following considerations.
 
 {{% rver-fragment name="v12-event-format" %}}
 
-### Authorization rules
+### Authorisation rules
 
 Events must be signed by the server denoted by the `sender` property.
 
-The types of state events that affect authorization are:
+The types of state events that affect authorisation are:
 
 -   [`m.room.create`](/client-server-api#mroomcreate)
 -   [`m.room.member`](/client-server-api#mroommember)
@@ -267,7 +267,7 @@ algorithm found in [room version 2](/rooms/v2) with the following modifications:
    now starts with an *empty* state map instead of the unconflicted state map.
 
 2. A new [definition](#definitions) for *conflicted state subgraph* has been added
-   which describes events that are required to authorize events during iterative
+   which describes events that are required to authorise events during iterative
    auth checks.
 
 3. To ensure the new conflicted state subgraph is actually referenced, the definition
@@ -405,11 +405,11 @@ events: for events *x* and *y*, *x* < *y* if
 The *iterative auth checks algorithm* takes as input an initial room
 state and a sorted list of state events, and constructs a new room state
 by iterating through the event list and applying the state event to the
-room state if the state event is allowed by the [authorization
-rules](/server-server-api#authorization-rules).
-If the state event is not allowed by the authorization rules, then the
+room state if the state event is allowed by the [authorisation
+rules](/server-server-api#authorisation-rules).
+If the state event is not allowed by the authorisation rules, then the
 event is ignored. If a `(event_type, state_key)` key that is required
-for checking the authorization rules is not present in the state, then
+for checking the authorisation rules is not present in the state, then
 the appropriate state event from the event's `auth_events` is used if
 the auth event is not rejected.
 

content/rooms/v2.md

@@ -59,7 +59,7 @@ Events in rooms of this version have the following structure:
 
 {{% rver-fragment name="v1-floaty-power-levels" %}}
 
-### Authorization rules
+### Authorisation rules
 
 {{% rver-fragment name="v1-auth-rules" %}}
 

content/rooms/v3.md

@@ -89,7 +89,7 @@ The complete structure of a event in a v3 room is shown below.
 
 {{% rver-fragment name="v1-floaty-power-levels" %}}
 
-### Authorization rules
+### Authorisation rules
 
 {{% boxes/note %}}
 {{% added-in v=3 %}} `m.room.redaction` events are subject to auth rules in

content/rooms/v4.md

@@ -78,7 +78,7 @@ the changes in this room version.
 
 {{% rver-fragment name="v1-floaty-power-levels" %}}
 
-### Authorization rules
+### Authorisation rules
 
 {{% rver-fragment name="v3-auth-rules" %}}
 

content/rooms/v5.md

@@ -60,7 +60,7 @@ completeness.
 
 {{% rver-fragment name="v1-floaty-power-levels" %}}
 
-### Authorization rules
+### Authorisation rules
 
 {{% rver-fragment name="v3-auth-rules" %}}
 

content/rooms/v6.md

@@ -6,7 +6,7 @@ version: 6
 ---
 
 This room version builds on [version 5](/rooms/v5) while changing various
-authorization rules performed on events.
+authorisation rules performed on events.
 
 ## Client considerations
 
@@ -47,20 +47,20 @@ no longer be formatted as floats.
 
 {{% rver-fragment name="v6-event-format" %}}
 
-### Authorization rules
+### Authorisation rules
 
 {{% added-in v=6 %}} Rule 4, which related specifically to events
 of type `m.room.aliases`, is removed. `m.room.aliases` events must still pass
-authorization checks relating to state events.
+authorisation checks relating to state events.
 
-{{% added-in v=6 %}} Additionally, the authorization rules for events of
+{{% added-in v=6 %}} Additionally, the authorisation rules for events of
 type `m.room.power_levels` now include a `notifications` property under
 `content`.  This updates rules 10.4 and 10.5 (now 9.4 and 9.5), which checked
 the `events` property.
 
 Events must be signed by the server denoted by the `sender` property.
 
-The types of state events that affect authorization are:
+The types of state events that affect authorisation are:
 
 -   [`m.room.create`](/client-server-api#mroomcreate)
 -   [`m.room.member`](/client-server-api#mroommember)

content/rooms/v7.md

@@ -27,18 +27,18 @@ regarding client considerations is the resource that Client-Server API
 use cases should reference.
 {{% /boxes/warning %}}
 
-Room version 7 adds new authorization rules for events to support knocking.
-[Room version 6](/rooms/v6) has details of other authorization rule changes,
+Room version 7 adds new authorisation rules for events to support knocking.
+[Room version 6](/rooms/v6) has details of other authorisation rule changes,
 as do the versions v6 is based upon.
 
-### Authorization rules
+### Authorisation rules
 
 {{% added-in v=7 %}} For checks performed upon `m.room.member` events, a
 new point for `membership=knock` is added.
 
 Events must be signed by the server denoted by the `sender` property.
 
-The types of state events that affect authorization are:
+The types of state events that affect authorisation are:
 
 -   [`m.room.create`](/client-server-api#mroomcreate)
 -   [`m.room.member`](/client-server-api#mroommember)

content/rooms/v8.md

@@ -82,7 +82,7 @@ Room version 8 adds a new join rule to allow members of a room to join another
 room without invite. Otherwise, the room version inherits all properties of
 [Room version 7](/rooms/v7).
 
-### Authorization rules
+### Authorisation rules
 
 {{% added-in v=8 %}} For checks performed upon `m.room.member` events, new
 points for handling `content.join_authorised_via_users_server` are added (Rule 4.2

content/rooms/v9.md

@@ -82,7 +82,7 @@ completeness.
 
 {{% rver-fragment name="v1-stringy-power-levels" %}}
 
-### Authorization rules
+### Authorisation rules
 
 {{% rver-fragment name="v8-auth-rules" %}}