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
 ---------------------------
@@ -24,7 +24,7 @@ There are two main human-readable IDs in question:
 
 - Room aliases
 - User IDs
- 
+
 Room aliases look like ``#localpart:domain``. These aliases point to opaque
 non human-readable room IDs. These pointers can change, so there is already an
 issue present with the same ID pointing to a different destination at a later
@@ -32,18 +32,19 @@ date.
 
 User IDs look like ``@localpart:domain``. These represent actual end-users, and
 unlike room aliases, there is no layer of indirection. This presents a much
-greater concern with homograph attacks. 
+greater concern with homograph attacks.
 
 Checks
 ------
 - Similar to web browsers.
 - blacklisted chars (e.g. non-printable characters)
-- mix of language sets from 'preferred' language not allowed. 
+- mix of language sets from 'preferred' language not allowed.
 - 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
 ---------
@@ -59,21 +60,22 @@ Rejecting
   rejected and why.
 - Error message SHOULD contain a ``failed_keys`` key which contains an array
   of strings which represent the keys which failed the check e.g::
-  
+
     failed_keys: [ user_id, room_alias ]
-  
+
 Other considerations
 --------------------
-- Basic security: Informational key on the event attached by HS to say "unsafe 
+- Basic security: Informational key on the event attached by HS to say "unsafe
   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.
-- High security: Outright rejection of the ID at the point of creation / 
+  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.
+  protocol complexity aside from rejection of an event.