Clean up

changelogs/server_server/newsfragments/1082.clarification

@@ -0,0 +1 @@
+Clarifies the historical handling of non-integer power levels.

content/server-server-api.md

@@ -137,6 +137,7 @@ to send. The process overall is as follows:
 {{% boxes/note %}}
 The reasons we require `<hostname>` rather than `<delegated_hostname>` for SRV
 delegation are:
+
   1. DNS is insecure (not all domains have DNSSEC), so the target of the delegation
       must prove that it is a valid delegate for `<hostname>` via TLS.
   2. Consistency with the recommendations in [RFC6125](https://datatracker.ietf.org/doc/html/rfc6125#section-6.2.1)
@@ -394,6 +395,25 @@ unspecified.
 For an `m.room.member` state event, the user given by the `state_key` of
 the event.
 
+**Historical String Power Levels** \
+
+ In order to maintain backwards compatibility with early implementations,
+ power levels can optionally be represented in string format instead of
+ integer format. A homeserver must be prepared to deal with this by parsing
+ the power level from a string. In these cases, the following formatting of the
+ power level string is allowed:
+
+- a single Base10 integer, no float values or decimal points, optionally with leading zeroes;
+- optionally with leading or trailing whitespace characters;
+- optionally prefixed with a single `-` or `+` character before the integer but after leading whitespace padding.
+
+ {{% boxes/warning %}}
+ This behaviour is preserved strictly for backward compatibility only. A
+ homeserver should take reasonable precautions to prevent users from
+ sending new power level events with string values and must never
+ populate the default power levels in a room as string values.
+ {{% /boxes/warning %}}
+
 #### Authorization rules
 
 The rules governing whether an event is authorized depends on a set of