Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Application-defined error codes #74

Closed
MikeBishop opened this issue Dec 5, 2016 · 2 comments
Closed

Application-defined error codes #74

MikeBishop opened this issue Dec 5, 2016 · 2 comments
Labels
-recovery -transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@MikeBishop
Copy link
Contributor

If applications want to terminate a stream or connection for a reason that isn't specific to the QUIC transport layer, they currently need to define their own error communication mechanism and wait for the frame to be acknowledged before they tell QUIC to terminate the stream/connection. That's not necessarily practical.

Could we carve out a segment of the error space and define them to be application-defined, so each application mapping can add whatever error codes are relevant to it? E.g. QUIC currently defines QUIC_DECOMPRESSION_FAILURE, but QUIC defines no compression. That's really there for HPACK, I presume.

We could do likewise for handshake errors, since that's also pluggable -- QUIC will have its own AEAD error codes, but things that could go wrong in the handshake will vary by which handshake protocol we're using.
@MikeBishop MikeBishop mentioned this issue Dec 22, 2016
Closed
@MikeBishop MikeBishop mentioned this issue Jan 7, 2017
Merged
MikeBishop added a commit that referenced this issue Jan 12, 2017
@MikeBishop
Merge pull request #131 from quicwg/error_space2
4c6d86d 
Marking #74 as 'confirm-consensus' and incorporating into draft.
@MikeBishop MikeBishop added the proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. label Jan 12, 2017
@MikeBishop
Copy link
Contributor Author

Proposed resolution in #131.

@mnot mnot added the design An issue that affects the design of the protocol; resolution requires consensus. label Jan 19, 2017
@mnot
Copy link
Member

mnot commented Jan 24, 2017

Discussed in Tokyo. Consensus confirmed in the room.

@mnot mnot closed this as completed Jan 24, 2017
@mnot mnot added -recovery notify-consensus and removed proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. labels Jan 24, 2017
@mnot mnot added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Apr 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-recovery -transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mnot @MikeBishop