How descriptive should EVENT_TYPE names be?

[rmarx]

For example:
PACKET_RECEIVED vs 1RTT_PACKET_RECEIVED
FRAME_NEW vs ACK_FRAME_NEW

For the leftmost entries, one would add a "type" field to the "DATA" value, e.g.,

{
     "type": "1RTT"
}

The shorter form makes that we have a much less large amount of different EVENT_TYPEs, but also makes it a bit harder to parse for human readers + harder to quickly filter for tools.
The longer form is much more explicit, but requires much more definition up-front and a proliferation of different EVENT_TYPEs.

We could also break consistency. i.e., the original qlog used PACKET_RECEIVED with an explicit type in the DATA, but used ACK_FRAME_NEW for individual frames.

Currently, we use the short-form, since this is most similar to quic-trace and keeps it consistent if we want to log frames both in their own events and again when sending a packet.

Extra edge-case: Errors
If you go for extreme short-form, you would just have a single ERROR EVENT_TYPE for each CATEGORY, and define the error type in the DATA.
However, for easier manual debugging, tracking the specific type of error directly in the EVENT_TYPE is arguably easier. Maybe an exception should be made for errors?

[rmarx]

In draft-01, we made the conscious choice to limit the number of events as much as possible and make most event data based on the Frame definitions that already existed for packet_sent and packet_received. Combined with proper naming of properties (e.g., packet_type instead of type) this enables fast parsing while removing the need for separate events for each possible signal.