Don't mention server-server stuff in client-server spec

specification/client_server_api.rst

@@ -29,12 +29,11 @@ API Standards
   Need to specify any HMAC or access_token lifetime/ratcheting tricks
   We need to specify capability negotiation for extensible transports
 
-The mandatory baseline for communication in Matrix is exchanging JSON objects
+The mandatory baseline for client-server communication in Matrix is exchanging
-over HTTP APIs. HTTPS is mandated as the baseline for server-server
+JSON objects over HTTP APIs. HTTPS is recommended for communication, although
-(federation) communication.  HTTPS is recommended for client-server
+HTTP may be supported as a fallback to support basic
-communication, although HTTP may be supported as a fallback to support basic
+HTTP clients. More efficient optional transports
-HTTP clients. More efficient optional transports for client-server
+will in future be supported as optional extensions - e.g. a
-communication will in future be supported as optional extensions - e.g. a
 packed binary encoding over stream-cipher encrypted TCP socket for
 low-bandwidth/low-roundtrip mobile usage. For the default HTTP transport, all
 API calls use a Content-Type of ``application/json``.  In addition, all strings
@@ -95,7 +94,7 @@ Some requests have unique error codes:
 
 .. _sect:txn_ids:
 
-The Client-Server API typically uses ``HTTP PUT`` to submit requests with a
+The client-server API typically uses ``HTTP PUT`` to submit requests with a
 client-generated transaction identifier. This means that these requests are
 idempotent. The scope of a transaction identifier is a particular access token.
 It **only** serves to identify new