HTTP/3 Datagram terminology is out of sync with RFC9297

[Jeremy Lainé]

Our HTTP/3 code dealing with datagrams dates back to before RFC9297 was published. This is reflected in the the use of the flow_id terminology which has been replace by quarter_stream_id.

This means we would need a breaking API change to use the proper terminology, with the following changes:

• DatagramReceived.flow_id needs to be renamed
• The first argument of H3Connection.send_datagram needs to be renamed

One thing which is not clear to me is whether we should actually use the "quarter stream ID" at the API boundary, or whether we consider this a transported-related detail and instead expose a "stream ID" like other events.

@bashi I would appreciate your insights here :)

[bashi]

I assume that fields in other H3Events directly represent the value from the wire protocol. If that's true, I'd use quarter_stream_id for consistency.

Using stream_id may also be an option I guess. However, this changes the semantics in addition to names. Clients need to be updated so that they don't divide stream_id by 4.

[Jeremy Lainé]

I assume that fields in other H3Events directly represent the value from the wire protocol. If that's true, I'd use quarter_stream_id for consistency.

Using stream_id may also be an option I guess. However, this changes the semantics in addition to names. Clients need to be updated so that they don't divide stream_id by 4.

Yes I appreciate it's a change in semantics. One way to force the update would be to force keywords-only arguments to send_datagram, that way there would be no confusion. I don't expect there are many clients using H3 datagrams though, it's probably just WPT and the aioquic demo HTTP/3 client/server.

My intuition is that using stream_id would cut down on the divide / multiply by four in clients, but I'm still on the fence..

[bashi]

I don't have strong opinion, assuming that documentations state the semantics of the field and the argument. Either way, I can help updating the wpt server.