initial_max_stream_id and, uni and bidi streams

[tatsuhiro-t]

Now we have separate uni and bidirectional stream ID spaces, but initial_max_stream_id in transport parameter does not say it applies to 1) both, or 2) uni only, or 3) bidi only.

[MikeBishop]

Yeah, we'll need two of those, I suppose.

[marten-seemann]

That will be really useful. An implementation that doesn't want to do uni-directional streams can just send 0 for the uni max stream ID.

[ianswett]

The max_stream_id was intended to apply to the type of stream it is(uni or bidi). It's necessary to have separate max stream ids for uni and bidi because otherwise you could easily end up in a situation where you have thousands of potentially usable stream ids of one type and a small number of the other.

[MikeBishop]

Are you suggesting that the max_stream_id transport parameter just occur twice?

[ianswett]

I missed that this was the initial max_stream_id in transport params. So disregard my previous statement.

I guess it appearing twice makes the most sense then?

[MikeBishop]

An endpoint MUST treat receipt of duplicate transport parameters as a connection error of type TRANSPORT_PARAMETER_ERROR.

So do we want to delete this prohibition (and replace it with rules about how other duplicates are processed, special-case this parameter as exempt from the prohibition, or have two instances of the parameter?

[ianswett]

Special cases are bad, so I'd rather not do that. We could allow a transport param be a list of stream ids?

[marten-seemann]

Why not create a new transport parameter? Seems the cleanest solution to me.

[tatsuhiro-t]

I'm fine to either listing 2 values, or introducing new transport parameter.
In my personal opinion, I'm lean to new transport parameter.