Clarify when server name is used and link to definition (#1862)

* Clarify when server name is used and link to definition

* Changelog

changelogs/client_server/newsfragments/1862.clarification

@@ -0,0 +1 @@
+Clarify when server name is used and link to the definition.

content/client-server-api/_index.md

@@ -355,9 +355,9 @@ as per the [CORS](#web-browser-clients) section in this specification.
 The `.well-known` method uses a JSON file at a predetermined location to
 specify parameter values. The flow for this method is as follows:
 
-1.  Extract the server name from the user's Matrix ID by splitting the
+1.  Extract the [server name](/appendices/#server-name) from the user's Matrix ID by splitting the
     Matrix ID at the first colon.
-2.  Extract the hostname from the server name.
+2.  Extract the hostname from the server name as described by the [grammar](/appendices/#server-name).
 3.  Make a GET request to `https://hostname/.well-known/matrix/client`.
     1.  If the returned status code is 404, then `IGNORE`.
     2.  If the returned status code is not 200, or the response body is

content/client-server-api/modules/sso_login.md

@@ -123,8 +123,8 @@ authentication is successful, the browser will be redirected to that
 
     For example, consider a web-based client at
     `https://client.example.com`, which wants to initiate SSO login on
-    the homeserver at `server.example.org`. It does this by storing the
+    the homeserver with [server name](/appendices/#server-name) `server.example.org`. It does this by storing the
-    homeserver name in a query parameter for the `redirectUrl`: it
+    server name in a query parameter for the `redirectUrl`: it
     redirects to
     `https://server.example.org/login/sso/redirect?redirectUrl=https://client.example.com?hs=server.example.org`.