Merge pull request #2112 from matrix-org/server_server/release-r0.1.2

Federation r0.1.2
client_server/release-r0.5.0^2
Travis Ralston 5 years ago committed by GitHub
commit 497c6875ac
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -1,3 +1,20 @@
r0.1.2
======
Spec Clarifications
-------------------
- Change examples to use example.org instead of a real domain. (`#1650 <https://github.com/matrix-org/matrix-doc/issues/1650>`_)
- Fix the ``access_token`` parameter in the open_id endpoint. (`#1906 <https://github.com/matrix-org/matrix-doc/issues/1906>`_)
- Fix various spelling mistakes throughout the specification. (`#1991 <https://github.com/matrix-org/matrix-doc/issues/1991>`_)
- Clarify exactly what invite_room_state consists of. (`#2067 <https://github.com/matrix-org/matrix-doc/issues/2067>`_)
- Clarify how ``valid_until_ts`` behaves with respect to room version. (`#2080 <https://github.com/matrix-org/matrix-doc/issues/2080>`_)
- Clarify which servers are supposed to sign events. (`#2081 <https://github.com/matrix-org/matrix-doc/issues/2081>`_)
- Clarify the key object definition for the key management API. (`#2083 <https://github.com/matrix-org/matrix-doc/issues/2083>`_)
- Clarify how many PDUs are contained in transaction objects for various endpoints. (`#2095 <https://github.com/matrix-org/matrix-doc/issues/2095>`_)
- Clarify that the trailing slash is optional on ``/keys/*`` endpoints when no key ID is requested. (`#2097 <https://github.com/matrix-org/matrix-doc/issues/2097>`_)
r0.1.1
======

@ -1 +0,0 @@
Change examples to use example.org instead of a real domain.

@ -1 +0,0 @@
Fix the ``access_token`` parameter in the open_id endpoint.

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

@ -1 +0,0 @@
Clarify exactly what invite_room_state consists of.

@ -1 +0,0 @@
Clarify how ``valid_until_ts`` behaves with respect to room version.

@ -1 +0,0 @@
Clarify which servers are supposed to sign events.

@ -1 +0,0 @@
Clarify the key object definition for the key management API.

@ -1 +0,0 @@
Clarify how many PDUs are contained in transaction objects for various endpoints.

@ -1 +0,0 @@
Clarify that the trailing slash is optional on ``/keys/*`` endpoints when no key ID is requested.

@ -280,4 +280,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.1.html#put-matrix-federation-v1-3pid-onbind
.. _`/3pid/onbind`: ../server_server/%SERVER_RELEASE_LABEL%.html#put-matrix-federation-v1-3pid-onbind

@ -63,7 +63,7 @@ If the client sends messages to users on remote domains, those messages should
be sent on to the remote servers via
`federation`_.
.. _`federation`: ../server_server/latest.html#send-to-device-messaging
.. _`federation`: ../server_server/%SERVER_RELEASE_LABEL%.html#send-to-device-messaging
.. TODO-spec:

@ -293,5 +293,5 @@ Events in version 1 rooms have the following structure:
{{definition_ss_pdu}}
.. _`auth events selection`: ../server_server/r0.1.1.html#auth-events-selection
.. _`Signing Events`: ../server_server/r0.1.1.html#signing-events
.. _`auth events selection`: ../server_server/%SERVER_RELEASE_LABEL%.html#auth-events-selection
.. _`Signing Events`: ../server_server/%SERVER_RELEASE_LABEL%.html#signing-events

@ -161,7 +161,7 @@ The *resolution* of a set of states is obtained as follows:
resolved state.
.. _`authorization rules`: ../server_server/r0.1.1.html#authorization-rules
.. _`authorization rules`: ../server_server/%SERVER_RELEASE_LABEL%.html#authorization-rules
Rejected events
+++++++++++++++

@ -120,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.1.html#signing-events
.. _`reference hash`: ../server_server/r0.1.1.html#reference-hashes
.. _`Signing Events`: ../server_server/%SERVER_RELEASE_LABEL%.html#signing-events
.. _`reference hash`: ../server_server/%SERVER_RELEASE_LABEL%.html#reference-hashes

@ -72,5 +72,5 @@ of ``auth_events`` and ``prev_events`` in a PDU.
.. _`Unpadded Base64`: ../appendices.html#unpadded-base64
.. _`Canonical JSON`: ../appendices.html#canonical-json
.. _`Signing Events`: ../server_server/r0.1.1.html#signing-events
.. _`reference hash`: ../server_server/r0.1.1.html#reference-hashes
.. _`Signing Events`: ../server_server/%SERVER_RELEASE_LABEL%.html#signing-events
.. _`reference hash`: ../server_server/%SERVER_RELEASE_LABEL%.html#reference-hashes

@ -48,8 +48,8 @@ Signing key validity period
When validating event signatures, servers MUST enforce the ``valid_until_ts`` property
from a key request is at least as large as the ``origin_server_ts`` for the event being
validated. Servers missing a copy of the signing key MUST try to obtain one via the
`GET /_matrix/key/v2/server <../server_server/r0.1.1.html#get-matrix-key-v2-server-keyid>`_
or `POST /_matrix/key/v2/query <../server_server/r0.1.1.html#post-matrix-key-v2-query>`_
`GET /_matrix/key/v2/server <../server_server/%SERVER_RELEASE_LABEL%.html#get-matrix-key-v2-server-keyid>`_
or `POST /_matrix/key/v2/query <../server_server/%SERVER_RELEASE_LABEL%.html#post-matrix-key-v2-query>`_
APIs. When using the ``/query`` endpoint, servers MUST set the ``minimum_valid_until_ts``
property to prompt the notary server to attempt to refresh the key if appropriate.

@ -80,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.2 <https://matrix.org/docs/spec/server_server/r0.1.2.html>`_
- `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>`_

Loading…
Cancel
Save