Draft: draft-ietf-quic-transport

Commentary: Editors discussed this and could do either . This is likely a nuisance topic for a meeting . Editors ' preference is for to decide this . can you either back out the " or " on the flow control thing , or add an " or " to the stream limit frame descriptions ? 
 FWIW , I think that the " or " needs to cover the following four frames : CRYPTO , STREAMS , MAXSTREAMS , STREAMSBLOCKED . 
 did you want to fix the examples listed in or shall I ? 
 I text for CRYPTO , MAXSTREAMS and STREAMSBLOCKED frames , however : for CRYPTO frames , there 's no flow control . It would be awkward to use a FLOWCONTROLERROR here , so I opted for just using a FRAMEENCODINGERROR , for MAXSTREAMS frames FRAMEENCODINGERROR is the only applicable error . We do have a STREAMLIMITERROR , but this error is described as " Too many streams opened " , and MAXSTREAMS does n't open any streams by itself . 
 Those seem like reasonable conclusions to me . I 'm happy taking this . Now I just need to ensure that the changelog is updated . 
 I 'm not sure if I follow the logic here . If there is no flow control , then I 'd presume that exceeding 2 < sup62</supbytes is totally fine , and therefore that that the receiver should not be required ( i.e. MUST ) to send an error . 
 There 's no flow control in the sense that you do n't advertise a window and you do n't update any window . 
 Are you suggesting that the CRYPTO stream has implicit limit of 2 < sup62</supbytes that can be transferred ? I think my question is how you would justify it . My claim is that it 's an unnecessary complexity . 
 That 's what 's written in the spec . I was not happy with our decision from Tokio to not communicate a limit for the data that can be sent on a CRYPTO stream , and have peers just drop any frames sent on that stream in the future instead . But that 's what the working group decided to do . 
 I think you are conflating two different issues . is an issue about the amount of data buffered , while this issue is about the maximum offset of data an endpoint can ultimately represent . Let me more practically explain why " MUST respond with a FRAMEENCODINGERROR " for a CRYPTO stream is a problem . The reason we have allowed the use of FLOWCONTROLERROR for STREAM frames is because that is an error that can be caught by the stream - level receive buffer ( and it 's logic ) , rather than the frame decoder . Stating that the error code MUST be FRAMEENCODINGERROR for CRYPTO streams in this particular case goes against that agreement . That logic that we used for STREAM frames can be equally applied to CRYPTO streams . The error code can either be CRYPTOBUFFEREXCEEDED or FLOWCONTROLERROR . I do n't mind either . But requiring FRAMEENCODINGERROR is different , because it could require the stream - level logic to respond either with a stream - level error code ( CRYPTOBUFFEREXCEEDED or FLOWCONTROLERROR ) and frame - level error code ( FRAMEDECODINGERROR ) based on the input . As can be seen , this requirement to distinguish between the two cases is the same as the one we argue for the STREAM frame case . 
 You 're right . I missed that we have a CRYPTOBUFFEREXCEEDED error . I 'll prepare a follow - up PR later today . Unfortunately , it looks like it wo n't make it into -24 any more though . 
 In the context of deciding what code to use for badly formatted frames : Originally posted by in I tend to agree with this . Let 's go through and try to apply some sort of consistency . Maybe even try to be principled about it . 
 How does this principle sound : If you can detect an error while parsing the frame , and without consulting any connection state , it should be a FRAMEENCODINGERROR . For everything that happens after frame parsing , we use the more concrete error types ( or PROTOCOL_VIOLATION ) . 
 +1 . To rephrase , as the name suggests , FRAMEENCODINGERROR indicates a syntactic ( i.e. , encoding ) error . But nothing else . 
 I 'd like to see a PR , but that seems like a good principle . 
 I prepared a PR , just waiting for to get merged to apply the principle there . 
 Can we call this editorial ? 
 It changes functional requirements about what error codes to send , so not really . 
 Discussed in Cupertino . Will be consensus - called . 
 I agree with that I would prefer FLOWCONTROLERROR since it is a bit more specific . Otherwise looks fine to me .
Paragraph (version B):
The largest offset delivered on a stream - the sum of the offset and
data length - cannot exceed 2^62-1.  Receipt of a frame that exceeds
this limit MUST be treated as a connection error of type
FRAME_ENCODING_ERROR.