Subject: wordsmithing priority

From: Patrick McManus <[email-masked]>
Date: Tue, 9 Dec 2014 12:42:27 -0500

These suggestions are editorial in nature only.

5.3.4 currently reads
" Similarly, streams that are in the "idle" state can be assigned
   priority or become a parent of other streams.  This allows for the
   creation of a grouping node in the dependency tree, which enables
   more flexible expressions of priority.
*Idle streams that are made a   parent of another stream are assigned a
default priority*
   (Section 5.3.5)."

I believe that last bolded bit isn't quite right. Idle-Unprioritized
streams that are made the parent of another stream are assigned the default
priority - but a group node can be in the idle state and explicitly have
its priority set.. at which point it can be made a parent of another stream
and should not be assigned the default priority as doing so rather
undermines the usefulness of a group node.

I propose:
" Similarly, streams that are in the "idle" state can be assigned
   priority or become a parent of other streams.  This allows for the
   creation of a grouping node in the dependency tree, which enables
   more flexible expressions of priority.  Idle streams begin with a default
   priority (Section 5.3.5)."

also in 6.3
"The PRIORITY frame is associated with an existing stream.  If a
   PRIORITY frame is received with a stream identifier of 0x0, the
   recipient MUST respond with a connection error (Section 5.4.1) of
   type PROTOCOL_ERROR."

To say associated with an existing stream begs the question of states
qualify as existing (idle? closed?)

I propose just editing out the first sentence:

  "If a PRIORITY frame is received with a stream identifier of 0x0, the
   recipient MUST respond with a connection error (Section 5.4.1) of
   type PROTOCOL_ERROR."

-Patrick

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Dec 2014 09:53:07 -0800

>    priority (Section 5.3.5)."

https://github.com/http2/http2-spec/pull/670

Because I'm nice.

>    recipient MUST respond with a connection error (Section 5.4.1) of

I didn't go that far, but you should take a look at my last email and
PR #669.  We had a mid-air collision on this very point.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 9 Dec 2014 12:58:28 -0500

> https://github.com/http2/http2-spec/pull/670

so true!

> PR #669.  We had a mid-air collision on this very point.
ack - wfm.