for room versions 6 and 7, clarify that events with rejected auth eve…

…nts must be rejected

Other room versions were updated in #1137, but not these ones.

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>

content/rooms/v6.md

@@ -88,15 +88,18 @@ The rules are as follows:
         version, reject.
     4.  If `content` has no `creator` property, reject.
     5.  Otherwise, allow.
-2.  Reject if event has `auth_events` that:
-    1.  have duplicate entries for a given `type` and `state_key` pair
-    2.  have entries whose `type` and `state_key` don't match those
+2.  Considering the event's `auth_events`:
+    1.  If there are duplicate entries for a given `type` and `state_key` pair,
+        reject.
+    2.  If there are entries whose `type` and `state_key` don't match those
         specified by the [auth events
         selection](/server-server-api#auth-events-selection)
-        algorithm described in the server specification.
-3.  If event does not have a `m.room.create` in its `auth_events`,
-    reject.
-4.  If type is `m.room.member`:
+        algorithm described in the server specification, reject.
+    3.  If there are entries which were themselves rejected under the [checks
+        performed on receipt of a
+        PDU](/server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
+    4. If there is no `m.room.create` event among the entries, reject.
+3.  If type is `m.room.member`:
     1.  If there is no `state_key` property, or no `membership` property in
         `content`, reject.
     2.  If `membership` is `join`:
@@ -154,15 +157,15 @@ The rules are as follows:
             than the `sender`'s power level, allow.
         3.  Otherwise, reject.
     6.  Otherwise, the membership is unknown. Reject.
-5.  If the `sender`'s current membership state is not `join`, reject.
-6.  If type is `m.room.third_party_invite`:
+4.  If the `sender`'s current membership state is not `join`, reject.
+5.  If type is `m.room.third_party_invite`:
     1.  Allow if and only if `sender`'s current power level is greater
         than or equal to the *invite level*.
-7.  If the event type's *required power level* is greater than the
+6.  If the event type's *required power level* is greater than the
     `sender`'s power level, reject.
-8.  If the event has a `state_key` that starts with an `@` and does not
+7.  If the event has a `state_key` that starts with an `@` and does not
     match the `sender`, reject.
-9. If type is `m.room.power_levels`:
+8. If type is `m.room.power_levels`:
     1.  If the `users` property in `content` is not an object with keys that
         are valid user IDs with values that are integers (or a string
         that is an integer), reject.
@@ -193,7 +196,7 @@ The rules are as follows:
         1.  If the new value is greater than the `sender`'s current power
             level, reject.
     8. Otherwise, allow.
-10. Otherwise, allow.
+9. Otherwise, allow.
 
 {{% boxes/note %}}
 Some consequences of these rules:

content/rooms/v7.md

@@ -74,15 +74,18 @@ The rules are as follows:
         version, reject.
     4.  If `content` has no `creator` property, reject.
     5.  Otherwise, allow.
-2.  Reject if event has `auth_events` that:
-    1.  have duplicate entries for a given `type` and `state_key` pair
-    2.  have entries whose `type` and `state_key` don't match those
+2.  Considering the event's `auth_events`:
+    1.  If there are duplicate entries for a given `type` and `state_key` pair,
+        reject.
+    2.  If there are entries whose `type` and `state_key` don't match those
         specified by the [auth events
         selection](/server-server-api#auth-events-selection)
-        algorithm described in the server specification.
-3.  If event does not have a `m.room.create` in its `auth_events`,
-    reject.
-4.  If type is `m.room.member`:
+        algorithm described in the server specification, reject.
+    3.  If there are entries which were themselves rejected under the [checks
+        performed on receipt of a
+        PDU](/server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
+    4. If there is no `m.room.create` event among the entries, reject.
+3.  If type is `m.room.member`:
     1.  If there is no `state_key` property, or no `membership` property in
         `content`, reject.
     2.  If `membership` is `join`:
@@ -150,15 +153,15 @@ The rules are as follows:
             or `join`, allow.
         4.  Otherwise, reject.
     7.  Otherwise, the membership is unknown. Reject.
-5.  If the `sender`'s current membership state is not `join`, reject.
-6.  If type is `m.room.third_party_invite`:
+4.  If the `sender`'s current membership state is not `join`, reject.
+5.  If type is `m.room.third_party_invite`:
     1.  Allow if and only if `sender`'s current power level is greater
         than or equal to the *invite level*.
-7.  If the event type's *required power level* is greater than the
+6.  If the event type's *required power level* is greater than the
     `sender`'s power level, reject.
-8.  If the event has a `state_key` that starts with an `@` and does not
+7.  If the event has a `state_key` that starts with an `@` and does not
     match the `sender`, reject.
-9. If type is `m.room.power_levels`:
+8. If type is `m.room.power_levels`:
     1.  If the `users` property in `content` is not an object with keys that
         are valid user IDs with values that are integers (or a string
         that is an integer), reject.
@@ -187,7 +190,7 @@ The rules are as follows:
         1.  If the new value is greater than the `sender`'s current power
             level, reject.
     8. Otherwise, allow..
-10. Otherwise, allow.
+9. Otherwise, allow.
 
 {{% boxes/note %}}
 Some consequences of these rules: