Draft: draft-ietf-quic-http

Commentary: Maybe takes things too far , please discuss . 
 Draft 17 says If I understand H3 Placeholders correctly , the PRIORITY frame would be used to set their priority too . Perhaps we can say : . 
 To me it seems that the current text is more accurate . While a PRIORITY frame might use a placeholder to designate the target , what is actually prioritized is the stream that carries the response . The transmission of the placeholder itself is never prioritized . 
 But the PRIORITY frame contains the Prioritized Element ID field , that allows us to set the priority of Placeholder type . 
 Yeah , my view is that it is an act of prioritizing a stream by specifying a placeholder ID that maps to the stream . Section 5.3 talks about prioritizing " streams " . 
 That 's a good observation , so I 'd go further to say that IMO the textual description of H3 prioritisation is not completely aligned with the protocol mechanisms . Cue to tell me I am completely off the mark :) 
 Also , the table of prioritized element types in seems to be duplicated 
 The two tables in section 4.2.3 are slightly different . 
 Correct , I just independently spotted that . Its logical but a bit annoying 
 makes some basic edits to section 4.2.3 , adding Table captions and linking to them from the paragraph above . It reworks 5.3 slightly to reframe the language toward describing a tree of abstract elements but still provides concrete examples of request prioritisation . 
 Yeah , there was originally one table and I had to split it to accommodate the current design . If anyone sees an elegant way to recombine them , I 'm fully supportive . 
 I thought perhaps make the labels multi line and then combine the last two columns of the second table onto the first . So there would be two colums containing two sub columns each , plus the left most bits column . I do n't know the Markdown foo to make that happen though . 
 My bad . I was confused . I now understand the issue and think that the PR will provide us the necessary fixes . 
 A comment on this text : we should be prioritizing requests and maybe pushes , not streams . 
 That 's a fair point I 'll see if I can incorporate that into the PR 
 Yes , I like this formulation better .
Paragraph (version A):
When a prioritized element is first created it has a default inital
weight of 16 and a default dependency.  Requests and placeholders are
dependent on the root of the priority tree, pushes are dependent on
the client request on which the PUSH_PROMISE frame was sent.
Paragraph (version A):
Requests may override the default intial values by including a
PRIORTIY frame (see frame-priority) at the beginning of the stream.
Pushes and placeholders may be later updated by sending a PRIORITY
frame on the control stream.
Paragraph (version B):
When a prioritized element is first created, it has a default initial
weight of 16 and a default dependency.  Requests and placeholders are
dependent on the root of the priority tree; pushes are dependent on
the client request on which the PUSH_PROMISE frame was sent.
Paragraph (version B):
Requests may override the default intial values by including a
PRIORTIY frame (see frame-priority) at the beginning of the stream.
These priorities can be updated by sending a PRIORITY frame on the
control stream.