Minor wording changes

specification/index.rst

@@ -434,16 +434,16 @@ There is no implicit ordering or hierarchy to room versions, and their principle
 are immutable once placed in the specification. Although there is a recommended
 set of versions, some rooms may benefit from features introduced by other versions.
 Rooms move between different versions by "upgrading" to the desired version. Due
-to versions not being ordered or hierarchical, this means a room can "upgrade" to
+to versions not being ordered or hierarchical, this means a room can "upgrade"
-version 1 from version 2, if it is so desired.
+from version 2 to version 1, if it is so desired.
 
 Room version grammar
 ~~~~~~~~~~~~~~~~~~~~
 
 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 split-brain situation due to them
+cause older servers to potentially end up in a split-brain situation due to not
-not understanding the new rules.
+understanding the new rules.
 
 A room version is defined as a string of characters which MUST NOT exceed 32
 codepoints in length. Room versions MUST NOT be empty and SHOULD contain only

specification/rooms/v1.rst

@@ -34,8 +34,8 @@ version room they are dealing with prior to executing a given algorithm.
 .. WARNING::
    Although room version 1 is the most popular room version, it is known to have
    undesirable effects. Servers implementing support for room version 1 should be
-   aware that restrictions should be generally relaxed and be aware that inconsistencies
+   aware that restrictions should be generally relaxed and that inconsistencies
-   may occur until room version 2 is ready and adopted.
+   may occur until room version 2 (or later) is ready and adopted.
 
 State resolution
 ~~~~~~~~~~~~~~~~

specification/rooms/v2.rst

@@ -60,8 +60,8 @@ Power events
   A *power event* is a state event with type ``m.room.power_levels`` or
   ``m.room.join_rules``, or a state event with type ``m.room.member`` where the
   ``membership`` is ``leave`` or ``ban`` and the ``sender`` does not match the
-  ``state_key``. The idea behind this is that power events are events that have
+  ``state_key``. The idea behind this is that power events are events that might
-  may remove someone's ability to do something in the room.
+  remove someone's ability to do something in the room.
 
 Unconflicted state map and conflicted state set
   The *unconflicted state map* is the state where the value of each key exists

specification/server_server_api.rst

@@ -752,9 +752,8 @@ is at the top)::
 Suppose E3 and E4 are both ``m.room.name`` events which set the name of the
 room. What should the name of the room be at E5?
 
-Servers must use the appropriate recursively-defined algorithm as required
+The algorithm to be used for state resolution depends on the room version. For
-by the room version. For a description of each room version's algorithm, please
+a description of each room version's algorithm, please see the `room version specification`_.
-see the `room version specification`_ .
 
 
 Backfilling and retrieving missing events