Room Version 6

specification/appendices/signing_json.rst

@@ -39,6 +39,17 @@ range where they can be accurately represented using IEEE double precision
 floating point numbers since a number of JSON libraries represent all numbers
 using this representation.
 
+.. WARNING::
+   Events in room versions 1, 2, 3, 4, and 5 might not be fully compliant with
+   these restrictions. Servers SHOULD be capable of handling JSON which is considered
+   invalid by these restrictions where possible.
+
+   The most notable consideration is that integers might not be in the range
+   specified above.
+
+.. Note::
+   Float values are not permitted by this encoding.
+
 .. code:: python
 
  import json

specification/rooms/v1.rst

@@ -352,6 +352,12 @@ Events in version 1 rooms have the following structure:
 
 {{definition_ss_pdu}}
 
+Canonical JSON
+~~~~~~~~~~~~~~
+
+Servers MUST NOT strictly enforce the JSON format specified in the
+`appendices <../appendices.html#canonical-json>`_ for the reasons described there.
+
 
 .. _`auth events selection`: ../server_server/%SERVER_RELEASE_LABEL%.html#auth-events-selection
 .. _`Signing Events`: ../server_server/%SERVER_RELEASE_LABEL%.html#signing-events

specification/rooms/v6.rst

@@ -89,3 +89,12 @@ For completeness, the changes to the auth rules can be represented as follows:
 
 The remaining rules are the same as in `room version 3 <v3.html#authorization-rules-for-events>`_
 (the last inherited room version to specify the authorization rules).
+
+Canonical JSON
+~~~~~~~~~~~~~~
+
+Servers MUST strictly enforce the JSON format specified in the
+`appendices <../appendices.html#canonical-json>`_. This translates to a 400 ``M_BAD_JSON`` error
+on most endpoints, or discarding of events over federation. For example, the federation API's
+``/send`` endpoint would discard the event whereas the Client Server API's ``/send/{eventType}``
+endpoint would return a ``M_BAD_JSON`` error.