Re: [quicwg/base-drafts] Greasing for Unidirectional Stream Types (#1490)

[Kazuho Oku <[e-mail]>]

@LPardue 
> So taking Martin's point in mind, what about something like:
> 
> _Implementations SHOULD NOT send stream types that the peer is not already known to support. Recipients of unknown stream types MUST send a STOP_SENDING frame with an error code of HTTP_UNKNOWN_STREAM_TYPE. Greased stream types are always classed as unknown and unsupported._

Sounds good to me. Though I might prefer using "MAY" instead of "MUST" for if STOP_SENDING should be sent. For example, if the entire flow of the unidirectional stream (i.e. from the beginning of the stream to EOS) fits in a single packet, I do not think that there is a strong reason to require the peer to send STOP_SENDING.

> It would help to provide some guidance for HTTP/QUIC extension authors to make it clear that a mechanism (e.g. SETTINGS) for negotiating extension stream types is required,

I am not sure if such requirement is necessary. In fact, I would argue that it would be beneficial allow extended stream types to be sent without negotiation.

For example, a server might send additional certificates before receiving the client's SETTINGS frame (i.e. by using in it's 0.5 RTT window, which would be idle time). Or, a client might send a cache digest before observing the server's SETTINGS frame.

To generalize the concept, I would argue that both frames and streams defined as extensions should be allowed to be sent without negotiation. The only differences are that streams can be reset by peer (by using STOP_SENDING), and that they would not suffer from HoLB (therefore it is sensible to use unidirectional streams with extended types for sending information that would have been exchanged using stream 0 of HTTP/2).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1490#issuecomment-400869779