Add changelogs

api/server-server/keys_server.yaml

@@ -27,7 +27,7 @@ paths:
     get:
       summary: Get the homeserver's public key(s)
       description: |-
-        Gets the homeserver's published TLS fingerprints and signing keys.
+        Gets the homeserver's published signing keys.
         The homeserver may have any number of active keys and may have a
         number of old keys.
 
@@ -49,7 +49,7 @@ paths:
           type: string
           description: |-
             **Deprecated**. Servers should not use this parameter and instead
-            opt to return all keys, not just the requested one. The key ID to 
+            opt to return all keys, not just the requested one. The key ID to
             look up.
           required: false
           x-example: "ed25519:abc123"

api/server-server/wellknown.yaml

@@ -35,9 +35,8 @@ paths:
             The delegated server information. The ``Content-Type`` for this response SHOULD
             be ``application/json``, however servers parsing the response should assume that
             the body is JSON regardless of type. Failures parsing the JSON or invalid data
-            provided in the resulting parsed JSON must result in server discovery failure (no
+            provided in the resulting parsed JSON should not result in discovery failure -
-            attempts should be made to continue finding an IP address/port number to connect
+            consult the server discovery process for information on how to continue.
-            to).
           examples:
             application/json: {
               "m.server": "delegated.example.com:1234"

changelogs/client_server/newsfragments/1838.clarification

@@ -0,0 +1 @@
+Fix various spelling mistakes throughout the specification.

changelogs/client_server/newsfragments/1853.clarification

@@ -0,0 +1 @@
+Fix various spelling mistakes throughout the specification.

changelogs/client_server/newsfragments/1860.clarification

@@ -0,0 +1 @@
+Fix various spelling mistakes throughout the specification.

changelogs/identity_service/newsfragments/1853.clarification

@@ -0,0 +1 @@
+Fix various spelling mistakes throughout the specification.

changelogs/server_server.rst

@@ -1,3 +1,13 @@
+r0.1.1
+======
+
+Spec Clarifications
+-------------------
+
+- Remove legacy references to TLS fingerprints. (`#1844 <https://github.com/matrix-org/matrix-doc/issues/1844>`_)
+- Clarify that servers should not fail to contact servers if ``/.well-known`` fails. (`#1855 <https://github.com/matrix-org/matrix-doc/issues/1855>`_)
+
+
 r0.1.0
 ======
 

scripts/templating/matrix_templates/units.py

@@ -774,7 +774,7 @@ class MatrixUnits(Units):
                 "Privileged server plugins",
             ), TypeTableRow(
                 "`Identity Service API <identity_service/"+is_ver+".html>`_",
-                "unstable",
+                is_ver,
                 "Mapping of third party IDs to Matrix IDs",
             ), TypeTableRow(
                 "`Push Gateway API <push_gateway/"+push_gw_ver+".html>`_",

specification/client_server_api.rst

@@ -73,7 +73,7 @@ MUST be encoded as UTF-8. Clients are authenticated using opaque
 ``access_token`` strings (see `Client Authentication`_ for details), passed as a
 query string parameter on all requests.
 
-The names of the API endponts for the HTTP transport follow a convention of
+The names of the API endpoints for the HTTP transport follow a convention of
 using underscores to separate words (for example ``/delete_devices``). The key
 names in JSON objects passed over the API also follow this convention.
 

specification/identity_service_api.rst

@@ -279,4 +279,4 @@ this isn't possible.
 .. _`Unpadded Base64`:  ../appendices.html#unpadded-base64
 .. _`3PID Types`:  ../appendices.html#pid-types
 .. _`Signing JSON`: ../appendices.html#signing-json
-.. _`/3pid/onbind`: ../server_server/r0.1.0.html#put-matrix-federation-v1-3pid-onbind
+.. _`/3pid/onbind`: ../server_server/r0.1.1.html#put-matrix-federation-v1-3pid-onbind

specification/rooms/v1.rst

@@ -18,6 +18,9 @@ Room Version 1
 This room version is the first ever version for rooms, and contains the building
 blocks for other room versions.
 
+.. contents:: Table of Contents
+.. sectnum::
+
 Server implementation components
 --------------------------------
 
@@ -290,5 +293,5 @@ Events in version 1 rooms have the following structure:
 {{definition_ss_pdu}}
 
 
-.. _`auth events selection`: ../../server_server/r0.1.0.html#auth-events-selection
+.. _`auth events selection`: ../../server_server/r0.1.1.html#auth-events-selection
-.. _`Signing Events`: ../../server_server/r0.1.0.html#signing-events
+.. _`Signing Events`: ../../server_server/r0.1.1.html#signing-events

specification/rooms/v2.rst

@@ -18,6 +18,9 @@ Room Version 2
 This room version builds off of `version 1 <v1.html>`_ with an improved state
 resolution algorithm.
 
+.. contents:: Table of Contents
+.. sectnum::
+
 Server implementation components
 --------------------------------
 
@@ -27,9 +30,8 @@ Server implementation components
    details contained here, and can safely ignore their presence.
 
 
-The algorithms defined here should only apply to version 2 rooms. Other algorithms
+Room version 2 uses the base components of `room version 1 <v1.html>`_, changing
-may be used by other room versions, and as such servers should be aware of which
+only the state resolution algorithm.
-version room they are dealing with prior to executing a given algorithm.
 
 
 State resolution
@@ -159,7 +161,7 @@ The *resolution* of a set of states is obtained as follows:
    resolved state.
 
 
-.. _`authorization rules`: ../server_server/r0.1.0.html#authorization-rules
+.. _`authorization rules`: ../server_server/r0.1.1.html#authorization-rules
 
 Rejected events
 +++++++++++++++

specification/rooms/v3.rst

@@ -24,6 +24,9 @@ This room version builds on `version 2 <v2.html>`_ with an improved event format
    where the contextual room of the request is using this room version. Rooms using
    other room versions should not be affected by these sweeping requirements.
 
+.. contents:: Table of Contents
+.. sectnum::
+
 
 Client considerations
 ---------------------
@@ -117,5 +120,5 @@ The remaining rules are the same as `room version 1 <v1.html#authorization-rules
 
 .. _`Unpadded Base64`:  ../../appendices.html#unpadded-base64
 .. _`Canonical JSON`: ../../appendices.html#canonical-json
-.. _`Signing Events`: ../../server_server/r0.1.0.html#signing-events
+.. _`Signing Events`: ../../server_server/r0.1.1.html#signing-events
-.. _`reference hash`: ../../server_server/r0.1.0.html#reference-hashes
+.. _`reference hash`: ../../server_server/r0.1.1.html#reference-hashes

specification/server_server_api.rst

@@ -16,6 +16,8 @@
 Federation API
 ==============
 
+{{unstable_warning_block_SERVER_RELEASE_LABEL}}
+
 Matrix homeservers use the Federation APIs (also known as server-server APIs)
 to communicate with each other. Homeservers use these APIs to push messages to
 each other in real-time, to retrieve historic messages from each other, and to
@@ -78,6 +80,7 @@ Other versions of this specification
 The following other versions are also available, in reverse chronological order:
 
 - `HEAD <https://matrix.org/docs/spec/server_server/unstable.html>`_: Includes all changes since the latest versioned release.
+- `r0.1.1 <https://matrix.org/docs/spec/server_server/r0.1.1.html>`_
 - `r0.1.0 <https://matrix.org/docs/spec/server_server/r0.1.0.html>`_
 
 Server discovery
@@ -157,14 +160,14 @@ The process overall is as follows:
      and a port of 8448, using a ``Host`` header of ``<delegated_hostname>``.
      The target server must present a valid certificate for ``<delegated_hostname>``.
 
-4. If the `/.well-known` request resulted in an error response, a server
+4. If the ``/.well-known`` request resulted in an error response, a server
    is found by resolving an SRV record for ``_matrix._tcp.<hostname>``. This
    may result in a hostname (to be resolved using AAAA or A records) and
    port. Requests are made to the resolved IP address and port, using 8448
    as a default port, with a ``Host`` header of ``<hostname>``. The target
    server must present a valid certificate for ``<hostname>``.
 
-5. If the `/.well-known` request returned an error response, and the SRV
+5. If the ``/.well-known`` request returned an error response, and the SRV
    record was not found, an IP address is resolved using AAAA and A records.
    Requests are made to the resolved IP address using port 8448 and a ``Host``
    header containing the ``<hostname>``. The target server must present a
@@ -220,12 +223,11 @@ server by querying other servers.
 Publishing Keys
 +++++++++++++++
 
-Homeservers publish the allowed TLS fingerprints and signing keys in a JSON
+Homeservers publish their signing keys in a JSON
 object at ``/_matrix/key/v2/server/{key_id}``. The response contains a list of
 ``verify_keys`` that are valid for signing federation requests made by the
 homeserver and for signing events. It contains a list of ``old_verify_keys`` which
-are only valid for signing events. Finally the response contains a list of TLS
+are only valid for signing events.
-certificate fingerprints to validate any connection made to the homeserver.
 
 {{keys_server_ss_http_api}}