Merge branch 'master' into travis/fix-changelog

5 years ago · b42310ab9d
parent 375104127c 3e06473305
commit b42310ab9d
12 changed files with 42 additions and 21 deletions
--- a/api/server-server/keys_server.yaml
+++ b/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"
--- a/api/server-server/wellknown.yaml
+++ b/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
-            attempts should be made to continue finding an IP address/port number to connect
-            to).
+            provided in the resulting parsed JSON should not result in discovery failure -
+            consult the server discovery process for information on how to continue.
          examples:
            application/json: {
              "m.server": "delegated.example.com:1234"
--- a/changelogs/client_server/newsfragments/1838.clarification
+++ b/changelogs/client_server/newsfragments/1838.clarification
@ -0,0 +1 @@
+Fix various spelling mistakes throughout the specification.
--- a/changelogs/client_server/newsfragments/1860.clarification
+++ b/changelogs/client_server/newsfragments/1860.clarification
@ -0,0 +1 @@
+Fix various spelling mistakes throughout the specification.
--- a/changelogs/server_server.rst
+++ b/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
 ======

--- a/scripts/templating/matrix_templates/units.py
+++ b/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>`_",
--- a/specification/client_server_api.rst
+++ b/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.

--- a/specification/identity_service_api.rst
+++ b/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
--- a/specification/rooms/v1.rst
+++ b/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
-.. _`Signing Events`: ../../server_server/r0.1.0.html#signing-events
+.. _`auth events selection`: ../../server_server/r0.1.1.html#auth-events-selection
+.. _`Signing Events`: ../../server_server/r0.1.1.html#signing-events
--- a/specification/rooms/v2.rst
+++ b/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
-may be used by other room versions, and as such servers should be aware of which
-version room they are dealing with prior to executing a given algorithm.
+Room version 2 uses the base components of `room version 1 <v1.html>`_, changing
+only the state resolution 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
 +++++++++++++++
--- a/specification/rooms/v3.rst
+++ b/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
-.. _`reference hash`: ../../server_server/r0.1.0.html#reference-hashes
+.. _`Signing Events`: ../../server_server/r0.1.1.html#signing-events
+.. _`reference hash`: ../../server_server/r0.1.1.html#reference-hashes
--- a/specification/server_server_api.rst
+++ b/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
-certificate fingerprints to validate any connection made to the homeserver.
+are only valid for signing events.

 {{keys_server_ss_http_api}}
				`@ -0,0 +1 @@`
				`Fix various spelling mistakes throughout the specification.`