Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-12 14:34:10 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Merge pull request #1382 from Half-Shot/hs/dns-to-be-hostname

Browse source 
Replace mentions of DNS name with hostname
This commit is contained in:
Will Hunt 2018-08-05 15:07:47 +01:00 committed by GitHub
parent dea16e9bbd c826edf23b
commit 12692f62e7
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 8 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
specification/appendices/identifier_grammar.rst
View file

@ -25,8 +25,7 @@ number of identifiers, as described below.
The server name represents the address at which the homeserver in question can The server name represents the address at which the homeserver in question can
be reached by other homeservers. The complete grammar is:: be reached by other homeservers. The complete grammar is::
server_name = dns_name [ ":" port] server_name = host [ ":" port]
dns_name = host
port = *DIGIT port = *DIGIT
where ``host`` is as defined by `RFC3986, section 3.2.2 where ``host`` is as defined by `RFC3986, section 3.2.2

15
specification/server_server_api.rst
View file

@ -23,7 +23,7 @@ Federation API
Matrix homeservers use the Federation APIs (also known as server-server APIs) 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 to communicate with each other. Homeservers use these APIs to push messages to
each other in real-time, to each other in real-time, to
historic messages from each other, and to historic messages from each other, and to
query profile and presence information about users on each other's servers. query profile and presence information about users on each other's servers.
@ -78,22 +78,21 @@ Server Discovery
Resolving Server Names Resolving Server Names
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
Each matrix homeserver is identified by a server name consisting of a DNS name Each matrix homeserver is identified by a server name consisting of a hostname
and an optional TLS port. and an optional TLS port.
.. code:: .. code::
server_name = dns_name [ ":" tls_port] server_name = hostname [ ":" tls_port]
dns_name = <host, see [RFC 3986], Section 3.2.2>
tls_port = *DIGIT tls_port = *DIGIT
.. ** .. **
If the port is present then the server is discovered by looking up an AAAA or If the port is present then the server is discovered by looking up an AAAA or
A record for the DNS name and connecting to the specified TLS port. If the port A record for the hostname and connecting to the specified TLS port. If the port
is absent then the server is discovered by looking up a ``_matrix._tcp`` SRV is absent then the server is discovered by looking up a ``_matrix._tcp`` SRV
record for the DNS name. If this record does not exist then the server is record for the hostname. If this record does not exist then the server is
discovered by looking up an AAAA or A record on the DNS name and taking the discovered by looking up an AAAA or A record on the hostname and taking the
default fallback port number of 8448. default fallback port number of 8448.
Homeservers may use SRV records to load balance requests between multiple TLS Homeservers may use SRV records to load balance requests between multiple TLS
endpoints or to failover to another endpoint if an endpoint fails. endpoints or to failover to another endpoint if an endpoint fails.
@ -630,7 +629,7 @@ if this optimisation fails.
Once the joining server has the room ID and the join candidates, it then needs Once the joining server has the room ID and the join candidates, it then needs
to obtain enough information about the room to fill in the required fields of to obtain enough information about the room to fill in the required fields of
the ``m.room.member`` event. It obtains this by selecting a resident from the the ``m.room.member`` event. It obtains this by selecting a resident from t
candidate list, and using the ``GET /make_join`` endpoint. The resident server candidate list, and using the ``GET /make_join`` endpoint. The resident server
will then reply with enough information for the joining server to fill in the will then reply with enough information for the joining server to fill in the
event. event.