Fix formating

drafts/human-id-rules.rst

@@ -12,11 +12,11 @@ phishing/spoofing of IDs, commonly known as a homograph attack.
 
 Web browers encountered this problem when International Domain Names were
 introduced. A variety of checks were put in place in order to protect users. If
-an address failed the check, the raw punycode would be displayed to disambiguate
-the address. Similar checks are performed by home servers in Matrix. However, 
-Matrix does not use punycode representations, and so does not show raw punycode 
-on a failed check. Instead, home servers must outright reject these misleading 
-IDs.
+an address failed the check, the raw punycode would be displayed to
+disambiguate the address. Similar checks are performed by home servers in
+Matrix. However, Matrix does not use punycode representations, and so does not
+show raw punycode on a failed check. Instead, home servers must outright reject
+these misleading IDs.
 
 Types of human-readable IDs
 ---------------------------
@@ -42,8 +42,9 @@ Checks
 - Language sets from CLDR dataset.
 - Treated in segments (localpart, domain)
 - Additional restrictions for ease of processing IDs.
-   - Room alias localparts MUST NOT have ``#`` or ``:``.
-   - User ID localparts MUST NOT have ``@`` or ``:``.
+
+  - Room alias localparts MUST NOT have ``#`` or ``:``.
+  - User ID localparts MUST NOT have ``@`` or ``:``.
 
 Rejecting
 ---------
@@ -68,12 +69,13 @@ Other considerations
   ID". Problem: clients can just ignore it, and since it will appear only very
   rarely, easy to forget when implementing clients.
 - Moderate security: Requires client handshake. Forces clients to implement
-  a check, else they cannot communicate with the misleading ID. However, this is
-  extra overhead in both client implementations and round-trips.
+  a check, else they cannot communicate with the misleading ID. However, this
+  is extra overhead in both client implementations and round-trips.
 - High security: Outright rejection of the ID at the point of creation /
   receiving event. Point of creation rejection is preferable to avoid the ID
-  entering the system in the first place. However, malicious HSes can just allow
-  the ID. Hence, other home servers must reject them if they see them in events.
-  Client never sees the problem ID, provided the HS is correctly implemented.
+  entering the system in the first place. However, malicious HSes can just
+  allow the ID. Hence, other home servers must reject them if they see them in
+  events. Client never sees the problem ID, provided the HS is correctly
+  implemented.
 - High security decided; client doesn't need to worry about it, no additional
   protocol complexity aside from rejection of an event.