Draft: draft-ietf-quic-http

Commentary: to the extent I 'm willing to do so . 
 Sec 4.1 and 4.1.2 do not explicitly define , , as stream errors .  says that is a stream error . It would be nice if they are explicitly defined as stream errors in Sec 4.1 and 4.1.2 . Also , it would be nice if each error code is categorized to either a connection error or a stream error in Table 4 . 
 Commenting as an individual . The error code space is shared between connection and streams . The action associated with a stream error or connection error cause QUIC transport frames to be emitted , which can use a code . H3 inherits H2 's design philosophy that endpoints can generate a connection error at will . So while there are specific cases that describe " treat X as stream error foo " , endpoints are also allowed to " treat X as connection error foo " . Constraining the error codes to different uses has a certain appeal . But then what do we say the the receiver of an error code of the wrong type should do ? Generate its own error ? I think this has come up a couple of times during H3 drafts but I 'm satisfied that the flexibility we have today is about the best we can do . 
 I also think " stream error " and " abort a stream " are unique and consistent terms used through the document . But I 'll let  spec to that point with his editor hat . 
 Even though categorization is not reasonable , Sec 4.1 , for instance , should say like " the server SHOULD abort its response and treat as a stream error of type H3REQUESTINCOMPLETE " . 
 " Abort " is a defined term in section 2.2 . I personally do n't see much clarity in the proposal , it threatens to add inconsistency to other places where streams are aborted due to application decisions rather than a protocol error . 
 My example proposal is to replace " the server SHOULD abort its response with the error code H3REQUESTINCOMPLETE " with " the server SHOULD abort its response and treat as a stream error of type H3REQUESTINCOMPLETE " in Sec 4.1 . I do n't understand why this would introduce inconsistency . 
 For that particular instance , I think it is not unreasonable to change the text from " SHOULD abort its response with the error code ... " to " SHOULD abort its response stream with the error code ... " , as the latter is the pattern that we use . Though I am not sure if such change is necessary ; I tend to agree with that the sentence is already clear ; " abort " is a defined word and use of " response " implies a stream . 
 WRT inconsistency , the editor would need to sweep for all instances of abort and reason about whether they need additional text or not . And there 's a risk that someone later on picks up on an inconsistency of usage because they did n't appreciate the nuance . Since adding more detail after an instance of seems duplicative , I would favour not adding any more . 
 I 'm okay with addition of " stream " since abort is defined as a stream operation . I do n't think we need to separate out " abort " and " stream error " as separate statements , because abort already describes what needs to be done . 
 If I was worried too much , no change is necessary . One alternative approach is to add a sentence like " errors in this section are stream errors " in the beginning of Sec 4 .
Paragraph (version A):
When a stream is closed, this indicates the end of the final HTTP
message.  Because some messages are large or unbounded, endpoints
SHOULD begin processing partial HTTP messages once enough of the
message has been received to make progress.  If a client-initiated
stream terminates without enough of the HTTP message to provide a
complete response, the server SHOULD abort its response with the
error code H3_REQUEST_INCOMPLETE; see errors.
Paragraph (version B):
When a stream is closed, this indicates the end of the final HTTP
message.  Because some messages are large or unbounded, endpoints
SHOULD begin processing partial HTTP messages once enough of the
message has been received to make progress.  If a client-initiated
stream terminates without enough of the HTTP message to provide a
complete response, the server SHOULD abort its response stream with
the error code H3_REQUEST_INCOMPLETE; see errors.