CLOSE_STREAM redundancies

[Martin Thomson <[e-mail]>]

draft-ietf-quic-reliable-stream-reset-01 includes a change to make the Application Protocol Error Code field optional.

I don't think that this is a necessary change.  There are essentially three cases for stream termination that this draft attempts to unify:

1. No data kept.  RESET_STREAM covers this.
2. Some data is kept.  This is the new functionality.
3. All data is kept.  STREAM with the FIN bit covers this already.

The draft rightly observes that the new frame with a retained limit of 0 is exactly equivalent to RESET_STREAM.  That's redundant, but I see no real harm in it other than the waste implied by sending the new frame type instead.  Changing this new frame so that a 0 could not be encoded would not save much, but it would make the frame processing more error prone.

Where things get interesting are those cases where there is no error.  The new version of the draft proposes that abandonment of a stream without delivering all of the (maybe promised) content is not necessarily an error condition.

That's a rather maximal design, covering the above options 1 and 2 in cases where there is no error (and case 3 where all data is delivered, but an error occurs anyway).  I don't see any way in which this is worth using a high-value codepoint for.  Yes, applications might consider a reduction in stream length as a useful tool, but - if they do - supplying an error code for use in signaling that is not a terrible thing.

Probably the most difficult aspect of this change is the API that would be implied by the use of non-error versions of the new frame.  An application would receive bytes up to (or maybe exceeding) the reliable length, but no error signal - no indication that the bytes were truncated.  I can easily imagine how that would lead to security problems in applications that were unprepared for the possibility.  

On the other hand, allowing the bytes to be delivered before generating an error signal is a fairly easy way to signal truncation, without losing those bytes.  In other words, the only safe option is to ensure that an error signal is always generated when anything less than an entire stream is delivered.

Cheers,
Martin

(Separately, this is the sort of change that really benefits from on-list discussion.  I couldn't find any justification for the change, even in GitHub: https://github.com/quicwg/reliable-stream-reset/pull/11 appears without much commentary.)