Blocking v. Vulnerable

draft-ietf-quic-qpack.md

@@ -96,42 +96,42 @@ reintroduced by HPACK when the loss includes a HEADERS frame.
 ## Avoiding Head-of-Line Blocking in HTTP/QUIC {#overview-hol-avoidance}
 
 In the example above, the header block on the second stream contained a
-reference to data which might not yet have been processed by the recipient.
-Such references are called "blocking," because the loss of a different packet
-can keep the reference from being usable.
+reference to data which might not yet have been processed by the recipient. Such
+references are called "vulnerable," because the loss of a different packet can
+keep the reference from being usable.
 
-The decoder can signal that it is willing to process blocking references by
+The decoder can signal that it is willing to process vulnerable references by
 setting SETTINGS_BLOCKING_HEADER_REFERENCES to a non-zero value.  In this case,
 the encoder can choose on a per-header-block basis whether to favor higher
-compression ratio (by permitting blocking references) or HoL resilience (by
+compression ratio (by emitting vulnerable references) or HoL resilience (by
 avoiding them). This is signaled by the BLOCKING flag in HEADERS and
 PUSH_PROMISE frames (see {{QUIC-HTTP}}).  Otherwise, the BLOCKING flag MUST be
 0.
 
-If a header block contains no blocking header fields, BLOCKING MUST be 0.
+If a header block contains no vulnerable header fields, BLOCKING MUST be 0.
 This implies that the header fields are represented either as references
 to dynamic table entries which are known to have been received, or as
 Literal header fields (see Section 6.2 of {{RFC7541}}).
 
 If a header block contains any header field which references dynamic table
 state which the peer might not have received yet, the BLOCKING flag MUST be
 set.  If the peer does not yet have the appropriate state, such blocks
-might not be processed on arrival.
+might not be processed on arrival.  These are considered "blocking."
 
 An encoder MUST NOT have more header blocks outstanding with the BLOCKING flag
 set than the value of SETTINGS_BLOCKING_HEADER_REFERENCES at any time.  Note
 that the decoder's count of references which are actually blocking will be less
-than or equal to the encoder's count of references which are potentially
-blocking.  If the decoder encounters more blocking references than it promised
-to support, it SHOULD treat this as a stream error of type
+than or equal to the encoder's count of references which are vulnerable
+(potentially blocking).  If the decoder encounters more blocking references than
+it promised to support, it SHOULD treat this as a stream error of type
 HTTP_QPACK_DECOMPRESSION_FAILED.
 
 The header block contains a prefix ({{absolute-index}}). This prefix contains
 table offset information that establishes total ordering among all headers,
 regardless of reordering in the transport (see {{overview-absolute}}).
 
 In blocking mode, the prefix additionally identifies the minimum state required
-to process any blocking references in the header block (see `Depends Index` in
+to process any vulnerable references in the header block (see `Depends Index` in
 {{overview-absolute}}).  The decoder keeps track of which entries have been
 added to its dynamic table.  The stream for a header with BLOCKING flag set is
 considered blocked by the decoder and can not be processed until all entries in
@@ -493,9 +493,9 @@ have outstanding (unacknowledged) references.
 An encoder MUST ensure that a header block which references a dynamic table
 entry is not received by the decoder after the referenced entry has already been
 evicted, and MUST ensure that the decoder will not suffer head-of-line blocking
-if the decoder has not opted to receive blocking references. Even if the decoder
-is willing to process blocking references, the encoder might choose to avoid
-them in certain cases.
+if the decoder has not opted to receive vulnerable references. Even if the
+decoder is willing to process blocking references, the encoder might choose to
+avoid them in certain cases.
 
 In order to enable this, the encoder will need to track outstanding
 (unacknowledged) header blocks and table updates using feedback received from