Draft: draft-ietf-quic-http

Commentary: These are some minor editorial things that should be considered to be addressed : 4.1 : " A server MAY send one or more PUSHPROMISE frames ( Section 7.2.5 ) before , after , or interleaved with the frames of a response message . These PUSHPROMISE frames are not part of the response ; see Section 4.4 for more details . These frames are not permitted in pushed responses ; a pushed response that includes PUSHPROMISE frames MUST be treated as a connection error of type H3FRAMEUNEXPECTED . " Especially the third sentence was hard to parse . Took me a while to realize that it tries to express that PUSHPROMISE frames are not allowed in pushed responses . I think it is primarily a language thing . However , is n't this dependent on stream type . So PUSHPROMISE are allowed on the client - initiated bi - directional stream but not on the server - initiated unidirectional stream . 4.1.1 : " For a listing of registered HTTP fields , see the " Hypertext Transfer Protocol ( HTTP ) Field Name Registry " maintained at " To avoid more confusion like the one I had in IETF last call . Can you add an Editors note ( to be removed before RFC publication ) that this registry does not yet exist , and is dependent on approval of [ SEMANTICS ] ? 7.2.4.1 : " SETTINGSMAXFIELDSECTION_SIZE ( 0x6 ): The default value is unlimited . See Section 4.1.1 for usage . " As the actual discussion of usage of this setting is in Section 4.1.1.3 would n't that be better to reference ? 
 I 'll take a look at cleaning it up , but I 'm hesitant to simply say " ca n't be used on unidirectional streams " because an extension might create a unidirectional stream that does allow PUSH_PROMISE frames for whatever reason . Maybe specifically stating that they ca n't be sent on   would work ? Good suggestion . Good suggestion ; probably we moved this text to subsections after the reference was written . 
 personal view has been that PUSHPROMISE is part of a request message . And so it has to abide by the rules there . Any attempt to change that requires a semantic extension to H3 . Which is what precisely does in order to allow PUSHPROMISE on a new stream type .
Paragraph (version A):
A server MAY send one or more PUSH_PROMISE frames (frame-push-
promise) before, after, or interleaved with the frames of a response
message.  These PUSH_PROMISE frames are not part of the response; see
server-push for more details.  These frames are not permitted in
pushed responses; a pushed response that includes PUSH_PROMISE frames
MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version B):
A server MAY send one or more PUSH_PROMISE frames (frame-push-
promise) before, after, or interleaved with the frames of a response
message.  These PUSH_PROMISE frames are not part of the response; see
server-push for more details.  PUSH_PROMISE frames are not permitted
on push streams; a pushed response that includes PUSH_PROMISE frames
MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version A):
The default value is unlimited.  See header-formatting for usage.
Paragraph (version B):
The default value is unlimited.  See header-size-constraints for
usage.