From 334bca26acf447258e33fc35d8a937ea00b16599 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Thu, 15 Dec 2016 14:17:17 -0800 Subject: [PATCH] Wording changes for Patrick --- draft-ietf-quic-http.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index c0b251886c..b501b203c6 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -443,11 +443,11 @@ is substantially different from {{!RFC7540}}. Individually, a SETTINGS parameter can also be referred to as a "setting". SETTINGS parameters are not negotiated; they describe characteristics of the -sending peer, which are used by the receiving peer. However, a negotiation can -be implied by the use of SETTINGS -- a peer uses SETTINGS to advertise a set of -supported values. The recipient can then choose which entries from this list are -also acceptable and proceed with the value it has chosen. (This choice could be -announced in a field of an extension frame, or in a value in SETTINGS.) +sending peer, which can be used by the receiving peer. However, a negotiation +can be implied by the use of SETTINGS -- a peer uses SETTINGS to advertise a set +of supported values. The recipient can then choose which entries from this list +are also acceptable and proceed with the value it has chosen. (This choice could +be announced in a field of an extension frame, or in its own value in SETTINGS.) Different values for the same parameter can be advertised by each peer. For example, a client might permit a very large HPACK state table while a server