Transport Draft Comments, mostly about error handling

[Martin Duke <[e-mail]>]

I'm deep into implementing the handler for a stream frame straight from the
-05 spec, and there seem to be a lot of ambiguities in the errors, as well
as things that should probably be prohibited:

(1) Section 8.14. Stream Frames for Stream 1 and above MUST NOT be in
Cleartext packets of any kind.

(2) Section 12.2 Stream Errors: We need to have some sort of special
considerations for handshake, especially cleartext packets. In particular,
any sort of cleartext packet that triggers an error should be dropped
rather than causing RST_STREAM or CONNECTION_CLOSE. Otherwise it is
trivially easy for a man-on-the-side to abort connections.

I believe, by the same logic, that bad 0RTT packets should simply be
dropped rather than reset.

As I see it, there are two possible responses to problems processing the
stream frame, each appropriate to different situations:
  - Internal error that doesn't break the stream (e.g. failure to allocate
memory for the stream reassembly queue element): drop the packet -- make
the peer retransmit and hope it works next time. Also do this for errors in
cleartext.
  - a stream error that still allows the receiver to find the end of the
frame (e.g. STREAM_STATE_ERROR). Send a RST_STREAM for that stream,but keep
processing the packet.

If this analysis is correct, it would be nice to specify it in the draft
explicity.

(4) Section 12. Error Handling: If a peer initiates an odd stream when it's
supposed to be even, or vice versa, what kind of error is that? Is it a
stream error or connection error?

(5) Section 12.3 Error Codes: For a Frame Error on a STREAM or ACK frame,
is the last two bytes of the error code the whole flags byte of the packet,
or just the mask (0xa0, 0xb0) of the frame type?

If I am not way off base on some or all of these points, I am happy to
create issues or PRs.

Martin Duke