Re: Split error codes in two

[Jana Iyengar <[e-mail]>]

On Tue, Sep 5, 2017 at 6:10 PM, Martin Thomson <[e-mail]>
wrote:

> On Wed, Sep 6, 2017 at 10:59 AM, Jana Iyengar <[e-mail]> wrote:
> > I think this (0-RTT) is a non-issue, but correct me if I'm wrong. This is
> > really about sending RST_STREAMs, not about anything else. I agree with
> > Victor and Nick that 0-RTT data cannot simply be retransmitted, but I
> think
> > this set of PRs is really about the wire protocol. The way I read it,
> QUIC
> > should never be sending RST_STREAMs of its own accord; that should be an
> > application-controlled mechanism. And to be clear, the only place that's
> not
> > true in gQUIC is when a RST_STREAM is received. gQUIC responds
> immediately
> > with a RST_STREAM.
>
> I've spun the 0-RTT discussion off onto another thread.  I think that
> there are issues, but hopefully they are minor.


I think they're orthogonal, but I'll go look at the other thread.


>
> > In the current draft, we've already changed that requirement: the
> > application is expected to generate a RST_STREAM in response to a
> received
> > RST_STREAM.
>
> That text was removed with the addition of STOP_SENDING.  (Or at least
> I couldn't find it).  I think that's the right answer, because this
> will be entirely discretionary on the part of applications.
>

Yup, I was just pointing out the reasons that we don't need RST_STREAM to
be a transport directive.


> (I'm not disagreeing with any of your conclusions, just pointing that
> out in case you thought that it was an important consideration.)
>