Revert "MUST NOT wait for peer's SETTINGS before sending one's own", …

…as it's stated elsewhere (pointed out by @MikeBishop)

This reverts commit 4664b5c.

draft-ietf-quic-http.md

@@ -1330,13 +1330,11 @@ If an endpoint receives a SETTINGS frame on a different stream, the endpoint
 MUST respond with a connection error of type HTTP_WRONG_STREAM.
 
 SETTINGS parameters are not negotiated; they describe characteristics of the
-sending peer, which can be used by the receiving peer. An endpoint MUST NOT wait
-for the peer's SETTINGS frame to arrive before sending it's own SETTINGS frame.
-However, a negotiation can be implied by the use of SETTINGS - each peer uses
-SETTINGS to advertise a set of supported values. The definition of the setting
-would describe how each peer combines the two sets to conclude which choice will
-be used.  SETTINGS does not provide a mechanism to identify when the choice
-takes effect.
+sending peer, which can be used by the receiving peer. However, a negotiation
+can be implied by the use of SETTINGS - each peer uses SETTINGS to advertise a
+set of supported values. The definition of the setting would describe how each
+peer combines the two sets to conclude which choice will be used.  SETTINGS does
+not provide a mechanism to identify when the choice takes effect.
 
 Different values for the same parameter can be advertised by each peer. For
 example, a client might be willing to consume a very large response header,