Carify usage and behaviour of stream resets

[thomaseizinger]

Inspired by this discussion: #412 (comment)

Currently, several specifications (mplex, yamux and WebRTC) talk about the capability of a "stream reset".

mplex properly documents, what a reset actually is and how clients are meant to behave when receiving a reset.

yamux also has a section on "Closing a stream" with similar semantics.

I'd like to suggest to introduce a "Resetting a stream" section perhaps under "Definitions" which documents how any libp2p substream should behave in regards to resets.

This will give us a canonical place to link to and clarify, what a stream reset actually is. The current state is confusing because the draft WebRTC spec for example talks about only terminating the sending part. See #412 (comment) for details.

cc @mxinden @marten-seemann

[mxinden]

I'd like to suggest to introduce a "Resetting a stream" section perhaps under "Definitions" which documents how any libp2p substream should behave in regards to resets.

Sounds good to me. @thomaseizinger would you mind proposing a paragraph?

[thomaseizinger]

I'd like to suggest to introduce a "Resetting a stream" section perhaps under "Definitions" which documents how any libp2p substream should behave in regards to resets.

Sounds good to me. @thomaseizinger would you mind proposing a paragraph?

Happy to make the changes yeah, just wanted to get a feeling for what people think before I waste time writing something up :)

[thomaseizinger]

Started here: #469

Feedback welcome!